正文
“世界观决定方法论”，中医和西医对人体的建模差别，决定治病的方法截然不同。例如前者用经络、寒热、干湿、虚实、阴阳来描述病理，后者用细胞、基因、细菌、病毒来看待问题，导致同一个疾病的不同处理手段。有些问题用这种模型来看容易解决，有些问题则用另一种模型描述更有效。盲目的用关系型数据库看待一切，是很多问题的根源。
以关系型数据库为中心的应用，一般都是单体应用（monolithic），虽然它们可能也会融合一些分布式的技术元素，扩容、扩展、弹性伸缩、响应变更等等这些非功能性需求，依然是它们所难以满足的。在看到这类架构的问题后，技术界开始出现混合编程（polyglot programming）、混合存储（polyglot persistence）和混合处理（polyglot processing - 例如大数据里的zeta架构）的潮流，微服务（Micro Services）的架构风格与理念也逐渐形成。
微服务具体实施的问题在于，停留在“理念”、“最佳实践”层面的东西，很难在一般垂直行业的IT落地，
因为面向业务的工程师们，关注点不在底层技术细节，无法投入资源去研究自己的平台，凡是能在垂直行业推广的技术，必须是具体有形的工具、API、框架。容器类技术作为看得见摸得着的、同时被运维人员和开发人员使用的工具链，对微服务的开发和运维，提供了无比巨大的推动力。虽然微服务本质上不依赖于容器，但是没有容器技术的支持，微服务在一般企业IT里的落地是不乐观的。
这就产生一个非常有趣的副作用 - 一旦技术人员习惯了容器化的观念，他们很可能不知不觉就走上了分布式架构的道路、潜移默化接受了微服务的思维，我们知道技术人员是很容易“心为物役”的，他们的抽象思考往往需要寄托在有型的工具上。例如Heroku的12-Factors（12律），总结了12项在云上开发分布式应用的最佳实践，我们可以看到，采用容器化的架构，很自然的就吻合这些实践。
总而言之，“去IOE”从它最开始的起源来看其实是去单体应用架构、去“数据库中心主义”，是分布式架构对传统企业技术套路的颠覆，而容器化一旦成为主流，分布式架构即会潜移默化不知不觉中成为企业IT架构的主流。
容器化既然被说的这么玄乎，那么是不是我们就该蜂拥而去的采用？个人认为，如果阁下的企业环境，并无特别适合 “微服务化” 的应用，那么个人揣测，阁下也并无采用容器技术的必要，即便是已经采用了SOA的技术架构与技术治理，千万别以为就顺理成章可以换一个时髦点的名字“微服务”。
SOA与微服务，其实有一些本质区别，哪怕是表面上有一些相似性
- 例如都叫“服务”（技术名词有时确实导致巨大的歧义）、都有服务注册与发现机制、甚至具体实施技术有一定重叠。在此列出一些区别（有商榷处，姑妄列出供讨论）：
-
从根本思想看，SOA是强调中央治理（central governance）的，服务之间大致松耦合但实践中其实有一定耦合，例如shared storage是常见的 - 同一个数据库上封装几个服务，避免数据直接暴露到外面，可后面依然是一个数据库；事实上当用到“治理”（governance）这样的字眼，本身就充满了中心化的意味。微服务则以去中心化为原则，强调share nothing、服务间高度松耦合，数据持久层被抽象为backing store - 甚至不需要是关系型数据库，每个服务各有自己的backing store
-
总体架构设计，SOA是一个top-down思维 - “顶层设计”，从业务切分模块，把模块之间关联变成封装服务之间的调用、集成。微服务是一个自下而上的bottom-up的思维，服务的粒度更小（否则何为“微”服务？），对服务本身上下文的假设更少，最重要一点，微服务通常是从当前服务的上下文衍生出来的
-
组织结构上看，SOA类型的项目团队，模块负责团队隶属于一个更大项目之下，实际中几乎不会独立运营运维。微服务，粒度小，强调单一责任，独立部署运维、自有生命周期。某种角度看，不同SOA项目之间是不同的Silo型团队负责的，而微服务严格来说一个服务对应一个跨职能团队
-
从关注点看，SOA强调的是SLA、compliance/regulation（合规）、audit（审计）等大型企业特色的“治理”，微服务关注点从来都是快速响应客户要求和市场变化以及快速创新，是敏捷型的。（所以微服务并不替代SOA）
-
从部署运维角度看，SOA出现于云计算之前，自动化部署、自动化运维并不是它的天然基因。微服务几乎可以说是云计算时代的产物，高度碎片化（与SOA型服务比），高度依赖于解决底层非功能性技术问题的PaaS/CaaS平台，天然符合多租户、需要DevOps支持
一个微服务通常很可能是通过从现有服务fork（开分支）、clone（直接复制）、mutate（变种）出来，这很有可能是违反我们在软件工程中一个所谓DRY（Don't Repeat Yourself）的原则 - 我们已经习惯于认为，剪贴代码是糟糕的、粗暴复制功能不好的，在理想主义的软件王国里，绝对没有拷贝粘贴的代码，也没有冗余的数据，更不应该有复制的服务。
然而，我们对世间事物的认识，往往是螺旋上升的，没有绝对的赞好、也不能武断的说坏，在现实这个不完美的世界里，除了编程大拿、代码洁癖者、技术原教旨主义者，我们必须接受一个现实，就是只关注快速实现业务需求的程序员、普通运维工程师是大多数，粘贴代码、复制部署服务可能就是大部分以业务功能为终极目标、以快速上线为首要任务的普通工程师的本能，quick-n-dirty是任何团队绕不开的取舍。微服务，通过结合容器技术，一定程度上接受了普通程序员克隆服务、克隆代码的“陋习” 。
-
系统升级，在条件允许的情况下，运维工程师最喜欢的可能是部署一套新的，旧的不碰。新的没问题，把旧的关闭；新的有问题，把旧的切换回来。微服务天然是考虑支持同一个服务的多个版本并存的，而容器则刚好是实现“不可变基础设施”（Immutable infrastructure）的最佳套路，这俩一拍即合
-
同一个服务，也许会逐渐演变成需要接受不同的运营约束（operational constraints）、或者针对不同的用户群，是不断收集新需求、重构代码、升级服务以保持单一服务支持不同业务需求？还是复制代码、克隆服务，在不同环境各自独立发展？对于快速敏捷支持不同的业务线、产品线，也许复制代码克隆服务是一个更高效的做法
Michael Nygard，一位曾任职私募股权交易机构的架构师，在他的“新常态”系列技术文章中，举了一个例子：他的公司有四十多个不同的交易席位（trading desk），分别在不同的市场采用不同的策略进行交易。每个交易席位都有自己的技术团队负责交易应用开发。如果他们像很多大企业一样采用一套单一的、集中式的交易系统，则任何交易组对系统的变更均会对其他组产生潜在的损害 - 因为变更影响他人、bug产生系统性风险、测试需要更繁复覆盖更充分、变更发布周期需要更长、升级需更复杂慎重、交易系统受影响面更，他把这些潜在能导致失败的影响称之为“失败域”（failure domain）。
Michael的雇主选择让每个交易组独立维护自己的小型、单一、功能聚焦的交易应用 - 开发工程师和交易员坐在一起工作、小团队作战、快速迭代，以此来最大程度缩小各交易组被动关联产生的“失败域”。这个场景，对于从事证券交易系统开发的工程师，是非常熟悉的。在这里我们看到两个极端的取舍：
