从SOA到微服务
小明毕业后为了户口，进入了一家大型国企的信息部门工作， 这个国企不差钱， 几十年来随着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年了，顺利的拿到了帝都的户口， 然后毫不迟疑的跳槽到了大胖的公司，去搞微服务去了。
小白科普：服务那点事儿
小明的公司向电子商务领域进军，开发了一个电商系统，功能没什么新奇的，无非就是用户管理、商品管理、订单管理、商品详情页、库存管理、支付管理等等。
系统刚开发的时候，所有的功能都放在一起，部署在一个机器上，这种应用被称为单体应用（monolithic application） ， 由于公司也没什么名气，流量也不大，单体应用可以轻松应对。
随着公司加大宣传力度， 流量越来越大， 这种单体应用的弊端越来越明显。
比如上周搞了一个宣传活动，注册用户送优惠券，那个用户管理的模块访问量暴涨， 小明虽然添加了几台虚拟服务器来做负载均衡应急， 但是这些新的服务器除了用户管理模块外，不得不连带其他模块一起部署（单体应用嘛）， 真是一种巨大的浪费。
小明不由地想： 要是能把用户管理单独拎出来就好了， 这样的话一个机器上就不部署别的应用了，专门部署用户管理，一个机器上可以部署好几个！ 多节省机器啊。
此外，随着逻辑的增加，应用变得越来越大，快长成一个接近200M的“大胖子”了， 各个模块之间也建立了千丝万缕的联系，慢慢地业务逻辑绞成了一团，原先定义良好的接口也变得混乱不堪，每次代码修改和系统上线都是一次重大挑战。
小明向领导建议： 把各个模块拆分成小应用吧， 让他们可以独立开发，灵活的部署。
如果哪个应用流量比较大，那就多部署几个，哪个应用用得少， 就少部署几个。
每个小应用可以独立开发、部署，非常灵活。
当然，应用之间还少不了交互，每个应用都得对外提供接口让别人访问， 例如想获得一个用户的信息就得访问这个URL : http://192.168.0.10/user/<userID>
这样的每个接口可以称为服务(Service)。
可是问题来了，对于每个应用来说，如果部署了多份，每个服务也会有多个实例， 有多个URL， 到底要调用哪一个呢？
http://192.168.0.10/user/<userID>
http://192.168.0.12/user/<userID>
http://192.168.0.13/user/<userID>
更烦人的是， 刚刚调用了192.168.0.13这个机器上的服务，过了一会儿， 由于流量小，不需要那么多机器， 这个机器上的服务实例下线了，就无法进行第二次调用了。
看来一个应用不能和特定机器上的服务绑死啊！
小明想了一个办法： 想要调用服务之前，先在一个叫做注册中心的地方根据名称查找一个服务，比如想查看用户信息了，可以这么干：
支付管理：给哥们来个getUserInfo的服务！
注册中心（忙活了半天）： 用这个吧 http://192.168.0.12/user/<userID>， 他的负载比较小
......支付管理开心地使用.....
支付管理：再给哥们来个getUserInfo的服务
注册中心： 用这个吧 http://192.168.0.13/user/<userID>， 刚才那个半天都不给我联系了，估计是下线了。
但是注册中心怎么知道有哪些服务呢？
小明早已想到这一层，他让各个服务主动前来报到，注册。
注册了还不算完， 各个服务必须定期前来签到（行业黑话叫做心跳），让注册中心知道服务还活着。
这种办法其实就叫做服务的注册和发现。
小明充分发挥了抽象的能力，他把调用方称为服务的消费者（Consumer）, 用户管理、订单管理、商品管理这些应用称为服务提供者(Provider)， 得到了下面这个图：
小明很得意：“看看我这个抽象多漂亮！”
他马上把这个宝图“献”给了领导， 领导看了一眼说： 这个图看着好眼熟啊， 奥，对了，我在Dubbo那里见过， 还有，当年我做SOA的时候也是用这种思路做服务的注册和查找， 看来我们现在遇到的问题和当年很类似嘛！
小明听了以后有点失望，失望之余又大为感慨： 看来我又造了一次轮子，技术在变， 但是基本的思想一直没变啊！
（完）