从SOA到微服务

                                                                                从SOA到微服务

                                                                                                                                                  2017-7-19     小B 

   小明毕业后为了户口，进入了一家大型国企的信息部门工作， 这个国企不差钱， 几十年来随着IT系统的发展， 也与时俱进地兴建了多个信息系统，只不过自家开发的极少， 从外边购买的极多， 虽然信息部也有开发能力， 但是当甲方的感觉是最妙的， 何况出了问题还可以把责任推出去。 在这些系统当中， 小一点儿的有自动化办公系统(OA) , 休假系统，车辆管理系统， 薪水支付系统， 大点儿的有客户关系管理系统， ERP系统 ..... 等等， 可以说是琳琅满目，让人目不暇接，几十年来IT发展的技术，几乎都能在公司的IT环境中找到。小明的工作之一就是维护现在的IT系统博物馆， 博物馆中大部分都是遗留系统， 能工作，但是非常的老旧。硬件平台， 软件环境，开发语言各部相同，都是异构的。就说那个休假系统吧，还是用上个世纪流行的Delphi 写的。 还有那个OA系统， 也是上个世纪的ASP,运行在IIS上。 虽然界面丑陋，勉强能用。也有一点新东西，比如上周上线的那个维修系统不就用了最新的前端技术嘛， 小明也着实激动了一阵，看了两天的React。有一天有个著名外企的销售来到了小明的公司，请信息部门的老大吃了饭，K了歌。。。好像还搞了些小明这些小兵不知道的秘密活动。第二天老大给国企老总做了汇报， 过了一段时间， 公司发文了： 为了提升IT效率，打破各个信息孤岛，实现各个信息系统之间的互联互通， 让业务和IT进行对齐， 达到业务敏捷性， 公司经慎重研究决定，邀请xxx公司作为咨询顾问， 从即日起开始实施SOA战略。小明看了一遍，愣住了，上面的字全都认识， 但连起来就不知道是什么意思， 虚头巴脑的， 唯一确定的是，咨询顾问要来了，要开始什么SOA了。顾问果然来了， 先给小明他们的信息部门洗了一次脑， 小明的脑海中被各种新式的名词所充斥： SOA, ESB, SCA, BEPL.... 下了课， 小明和同事们讨论了很久， 模模糊糊的明白了要做什么事情。 好像是把这些遗留的异构系统包装成粗粒度的服务， 还是 Web 服务，可以通过Http来访问， 然后呢， 让大家互相调用， 甚至可以把这些服务进行编排，形成一个大的业务流程， 完成更高层次的业务， 听起来挺有意思的。外企的销售非常精明， 趁势卖了一大批硬件和软件， 他们的技术团队还确实帮着做了一个小的验证系统， 实现了一个业务场景，展示给公司老总看， 老总非常满意： 不错， 我们公司又一次站到了IT技术的前沿！然后就没有下文了， 领导们似乎忘记了， SOA似乎没有发生过，互联互通呢？ 业务敏捷呢？小明很困惑，周末约着同学张大胖去吃饭。张大胖在一个互联网公司工作， 主要是做网上约车系统， 用的都是最前沿的技术， 他说： 听起来你们要把这些遗留的异构系统做数据/信息的集成啊， 只是没有做下去而已， 国企嘛可以理解。 你知道我们公司在干什么事儿吗？小明说：“不会和我们一样吧？”“完全不同！ 我们公司才成立几年啊， 最重要的就是这个约车系统， 当然我们现在发展的很快，这三年以来系统已经快变成一个巨无霸了， 代码已经达到百万行级别， 没人能搞明白了， 代码库非常难于管理， 冲突不断。 系统部署也非常困难， 一点点小改动都需要巨无霸式的整体部署， 你能想象得到吗， 我们系统重启一次得15分钟！”“我赛， 这么慢？ 不可思议，我用过你们的打车软件， 用起来还可以啊？”“唉， 金玉其外，败絮其中， 你不知道我们每次发布有多痛苦， 但是竞争激烈， 我们还得频繁发布。 所以我们做的事情和你们相反， 不是集成， 而是拆分！ 把一个巨无霸变成一些小的组件， 让这些小组件能完全独立的开发， 测试和部署。”“那你们的开发团队怎么办？”　小明问。“我们的组织结构也要随着这些小组件来重构啊，你看我们分成了“乘客管理”，“司机管理”，“旅程管理”，“支付管理”等好多组，　每个组只负责他们特定的一块儿功能，　并且每个组里边都有设计，开发，测试，部署等人员，一应俱全， 他们从头到尾全程负责。”“有意思啊，这些小组件都是独立的，每个组件实例都是一个进程吧， 那这些小组件怎么交互？　难道也是通过我们公司所用的Web service ?”“不不， 我们不用那重量级的Web service , 什么WSDL, 什么SOAP, 我们统统不用， 我们只用最轻量级的、基于Http 的Restful 来对外提供接口”小明突然想到一个问题：“你们每个部门负责一个特定功能，那数据怎么办？还用统一的数据库吗？”“这是个老大难问题，我们得做数据库的拆分啊，唉，　一言难尽。”小明说 ：“可以理解，不过这样以来确实是更加敏捷了。”大胖说：“这还不是最厉害的，最厉害的是我们能快速的自动化的部署这些小组件，并且能为他们创建很多实例来运行，有一个挂掉了也没关系，别人可以调用那些还在运行的。”“所以关键点就是这些小组件对外提供的服务是无状态的，对吧？”“没错”　 大胖说，　“这一点和你们的SOA是一样的， 对了， 告诉你一个小秘密，我们在生产环境会做一些‘猴子测试’，通过写脚本随机的停掉一些实例，看看我们的系统运行的怎么样”小明说：“厉害啊，你们都玩的可都是心跳啊。”“木有办法，只有在生产环境才能发现真正的问题啊”“难道你们的这种方式没有缺点吗？”“当然有了， 就拿数据库来说吧， 数据做了分区， 一致性怎么保证啊？ 选择分布式事务非常麻烦， 有时候不得不选择最终一致性来妥协； 还有服务多了， 客户调用起来非常的麻烦， 所以经常得把多个接口API封装，对外提供一个简单的接口 ； 当然这种基于HTTP的调用远没有原来的在一个进程内的方式效率高。 还有一个要命的问题就是监控，你想想这么多运行的实例， 互相之间有调用关系，一个地方出错了， 怎么追踪啊，很麻烦。”“不管如何， 你们这种把系统拆分，让一个独立的组织负责独立的部分还是很敏捷啊， 对了，你说的小组件，难道没有一个像SOA这样的高大上名称吗？”“当然有了， 业界把这种方式叫做微服务！ 虽然这个词不能完整的表达我们做的事情。 我现在很期望Martin Flower 给它起个更贴切的名称，就像Dependency Injection 那样， 比之前的IoC强多了。 ”吃过饭回去的路上，小明心想：天下大势，真是分久必合，合久必分啊， 我们在零散系统的集成， 大胖他们又在搞巨无霸应用的拆分。相比而言，小明还是羡慕大胖，羡慕他们公司的朝气蓬勃。 他虽然明白自己所在国企的信息系统和大胖做的不一样， 但是暮气沉沉的感觉让人看不到希望， 再这么混下去， 热爱的技术可就真的废了。过了年，小明已经在国企服务了3年了，顺利的拿到了帝都的户口， 然后毫不迟疑的跳槽到了大胖的公司，去搞微服务去了。