导语：

微服务是起源于SOA的一个流行架构，正受到越来越广泛的关注。 本文从历史的角度来分析SOA和微服务的流行的原因，它们的历史渊源，和它们的异同。

一.SOA到微服务的历史

SOA产生前的原始社会

在我小时候， 老师对我们说: “到2000年就实现四个现代化了，到时后火箭卫星满天飞，机器人会帮我们干所有的事情”。 弹指间21世纪到了，童年的梦想也破灭了。 说好的机器人在哪里? 后来当电脑越来越普及，在工作生活中变得越来越不可替代。 我们慢慢意识到，电脑就是老师说的机器人。 在没有电脑前。 办公室里是这样的: 几百个文员，秘书密集在一起，用打字机的按键声和清亮的换行声交织出一部交响曲。 后来企业借助电脑慢慢地开发出来各式各样的程序。 姑娘们被解放了出来喽。 轻敲几下键盘，全公司的工资单就打印出来了，再也不用担心刚好做的指甲敲打字机弄坏了。 革命!

SOA的萌芽阶段

随着企业的IT化越来越成熟，各式各样的系统越来越多，老板们已经不满足于简单的应用了。 企业需要的是跨部门和各业务间的集成。 这时候EAI (Enterprise Application Integration)这个概念出来了。 出现了各式各样应用集成的标准，如COM/DCOM，Corba，RMI等等。 后来，XML标准出现了。 被COM，Corba虐惨了的码农们惊呼终于有了一个足够灵活的标准了。 XML在本世纪初成为了一个明星。 渐渐地，人们开始用通过XML和其他系统沟通，出现了web service，也出现了各种反人类的WS-XX标准和SOAP，WSDL等协议。 SOA(Service Oriented Architecture) 这个概念应运而生。

SOA的发展和衰落

SOA这个东西其实写几十万字都讲不清楚。 砖家们教导我们，SOA是一种面向服务的体系结构。 总之就是高大上的代名词。 如果你说SOA不就是web service吗，马上会有人说你”图样图森破”。 在实践中，我们发现SOA 就像面上对象的架构一样，包含了很多种设计模式。 企业可以根据自己的需要选择合适的SOA模式。 几年过去了，大家慢慢把注意力集中到更高大上的东西上，网格计算，云计算，大数据。 SOA好像慢慢被人淡忘了。

二. 微服务产生的历史契机和挑战

将近10年过去了，SOA的热潮渐渐冷却了。 IT界也发生了一些翻天覆地的变化:

1.企业级应用不再一家独大了。 越来越多的软件公司开发出更多的面向广大互联网消费者的应用。 对服务的性能，可扩展性和高可用性要求越来越高。

2.开源软件越来越多了，越来越多的快速开发框架和编程语言出现了。

3.虚拟化技术: 一个服务器不再是那么珍贵了。 一个松耦合的服务可以被布署在轻量级的虚机或者容器上。

4.云计算服务出现了，IaaS，PaaS成熟了，管理基础架构不再是大难题了。

5.敏捷开发成为主流了，DevOps概念出现了。

6.越来越多的客户端需要满足，各种前端技术越来越成熟了，后端基本只需要提供服务了。

7.轻量级的服务协议出现了 (json，RESTful API)，特别适合被前端的JS调用。

与此同时，我们发现原来的”巨石型”(monolithic)的应用变得越来越庞大，复杂，以至于:

1.开发越来越低效。 改一个bug会生出两个bug。

2.想淘汰一个过时的框架或技术几乎不可能。

3.想扩展某个小服务或模块必须扩展整个巨大应用。

4.不适合敏捷开发了。 各种依赖关系错中复杂像一碗炸酱面。

这时我们再回头看SOA的概念时，我们发现以前那些高大上的想法现在居然变成现实了。 在SOA的众多设计模式里，我们去芜存精发展出了一套微服务的架构。 那些W3C，OASIS，J2EE砖家们订下的标准被无情地摒弃。 我们终于开始拥抱那些草根标准，如RESTful，json等。 再有人说我们图样图森破时，我们终于可以骄傲地说他”sometimes naive”。 SOA没有那么神秘，不就是web service吗?

三.SOA和微服务的不同

SOA喜欢重用，微服务喜欢重写。

SOA的主要目的是为了企业各个系统更加容易地融合在一起。 说到SOA不得不说ESB(Enterprise Service Bus)。 ESB是什么? 很高大上就是了。 可以把ESB想象成一个连接所有企业级服务的脚手架。 通过service broker，它可以把不同数据格式或模型转成canonical格式，把XML的输入转成CSV传给legacy服务，把SOAP 1.1服务转成 SOAP 1.2等等。 它还可以把一个服务路由到另一个服务上，也可以集中化管理业务逻辑，规则和验证等等。 它还有一个重要功能是消息队列和事件驱动的消息传递，比如把JMS服务转化成SOAP协议。 各服务间可能有复杂的依赖关系。

微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。 我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然后单独布署。 它通常不依赖其他服务。 微服务中常用的API Gateway的模式主要目的也不是重用代码，而是减少客户端和服务间的往来。 API gateway模式不等同与Facade模式，我们可以使用如future之类的调用，甚至返回不完整数据。

SOA喜欢水平服务，微服务喜欢垂直服务

SOA设计喜欢给服务分层(如Service Layers模式)。 我们常常见到一个Entity服务层的设计，美其名曰Data Access Layer。 这种设计要求所有的服务都通过这个Entity服务层来获取数据。 这种设计以我来看非常不灵活，比如每次数据层的改动都可能影响到所有业务层的服务。 而每个微服务通常有它自己独立的data store。 我们在拆分数据库时可以适当的做些去范式化(denormalization)，让它不需要依赖其他服务的数据。 微服务通常是直接面对用户的，每个微服务通常直接为用户提供某个功能。 类似的功能可能针对手机有一个服务，针对机顶盒是另外一个服务。 在SOA设计模式中这种情况通常会用到Multi-Channel Endpoint的模式返回一个大而全的结果兼顾到所有的客户端的需求。

SOA喜欢自上而下，微服务喜欢自下而上

SOA架构在设计开始时会先定义好服务合同(service contract)。 它喜欢集中管理所有的服务，包括集中管理业务逻辑，数据，流程，schema，等等。 它使用Enterprise Inventory和Service Composition等方法来集中管理服务。 SOA架构通常会预先把每个模块服务接口都定义好。 模块系统间的通讯必须遵守这些接口，各服务是针对他们的调用者。 SOA架构适用于TOGAF之类的架构方法论，而微服务则敏捷得多。 只要用户用得到，就先把这个服务挖出来。

四.微服务架构面临的挑战

微服务这么好，看上去好简单。 实现微服务面临许多挑战：

1.对运维的挑战，如何管理，布署和监视众多服务

自动部署和监控是微服务的最低要求。微服务的Docker化也是当今最主流的部署方式。 可以考虑利用类似Cloud Foundry之类的PaaS平台。

2.分布式事务的管理和数据的一致性

以往巨石型的应用里用到的分布式事务管理在微服务架构里变得不可能了。可以考虑通过CQRS架构用Event Sourcing模式来达到"最终"的一致性。

3.客户端和各服务间服务管理，版本管理，服务发现

这可能是微服务最大的挑战之一。 Netflix在这方面做得很好，可以考虑用他们的开源框架Erueka、API的向前兼容。

4.多团队多项目的管理，团队间的沟通

要有很强的项目经理来统筹所有服务的上线和部署计划。

5.安全的管理

用API Gateway集中管理安全，或者使用OAuth2之类的API授权。

6.还有许多，包括所有SOA已经解决了的问题

我们在享受今天琳琅满目地IT产品的同时，不要忘了有多少码农艰辛的付出。 在硬件落后，软件封闭的过去，有多少码农无私地奉献才有了今天这个百花齐放的局面。 今天的码农是非常幸福的，我们有这么多的资源让我们更快更好更自由地开发软件。 经过多年的试错，我们在分布式计算上总算走上了正轨，一点点挑战算什么。