微服务的“前世今生”
请原谅作者作为“标题党”，为文章用了一个“巨大”的标题。但本意是想从自己对微服务的理解开始，与大家一起探讨微服务的起源和诞生，从而抛砖引玉，共同探讨微服务应用架构。所以有不当之处，还请各位看官“拍砖”指正。
微服务的概念在近几年非常火，不仅在各大互联网公司都有大规模的应用，并且也逐渐被一些传统的制造业企业慢慢接受。那么为什么微服务能够如此盛行？它是从何而来？去向又是何方？下面我们尝试着追根溯源。
微服务诞生的时代背景
下图被称为浴缸曲线，来自Niels Pflaeging的书《Organizefor Complexity》，它主要反映西方上个世纪到现在经济模式的变迁，形状看起来像浴缸，故而得名：
1. 1900 年以前被称为前工业时代，也称手工艺时代，这个时代价值创造的主体是掌握技艺的手工艺者，高度动态，局部市场，客制化是这个时代市场的主要特点；
2. 1900 年到 1980 左右被称为泰勒工业时代，这个时代价值创造的主体是机器，市场广阔缓慢，竞争少，通过机器化和规模化生产提升效率和比拼低成本是这个时代市场的主要特点；
3. 1980 到现在被称为后工业时代，也称全球经济时代，这个时代价值创造的主体是知识工人，新兴行业不断对传统行业施加竞争压力，高度动态，持续快速地响应市场需求是在这个时代市场中取得成功的关键。
注意，我们目前所处的“后工业时代”的特点就是微服务诞生的时代背景：“高度动态，持续快速地响应市场需求是在这个时代市场中取得成功的关键”。“持续快速地相应市场需求”成了企业安身立命之本。那么如何能够快速响应市场需求的变化呢？(其实正是在这个背景之下，精益思想，敏捷开发管理，云平台，DevOps等等一系列思想，方法和技术才能如火山爆发式的红火起来)
微服务的诞生
影响企业“持续快速地响应市场需求的变化”的因素很多，但从企业应用系统架构的角度来讲，就需要一个能够面对变化的，甚至是主动拥抱变化的架构。
那么单体应用架构能不能满足企业应对变化的要求呢？两天到一周的问题修复周期；两周到三周，甚至一两个月的需求变更周期；一个月到两个月的版本发布计划……也许在某些需求比较稳定，市场变化不明显的领域，这样的频率是可以接受的。但是在“你死我活”，竞争激烈的领域，如果只具备这样的响应力则注定是要被动挨打的。
那么是什么样的原因导致单体应用“快”不起来？所有代码都放在一起，大量紧耦合的代码导致应用模块间的界限日益模糊，改一处而动全身，有时程序员甚至无从下手，拖慢了修复问题和修改变更的速度；当频繁变更时，就需要做大量的回归测试，如果当测试过程中发现问题还要重新修改，延长了测试时间；所有功能都被打进一个发布包中，往往需要彼此等待大部分或所有模块开发，测试完成才能进行统一部署，拖长了发布时间……单体应用就像代步用的马车，你可以增加马匹的数量来增强马车的运输能力，却永远受限于马的速度。这时我们需要一种可以真正提高速度的工具——一辆真正的汽车：微服务。
什么是微服务？为什么微服务能够真正的“快”起来？
Martin Fowler（https://martinfowler.com/）是如此定义微服务的“In short, the microservice architectural style is an approach todeveloping a single application as a suite of small services, each running inits own process and communicating with lightweight mechanisms, often an HTTPresource API”，如下图所示：
简单的说，微服务架构就是以业务域或业务功能为边界，将一个大而全的应用拆分为可以独立开发，独立部署，独立测试，独立运行的一组小的应用，并且使用轻量级，通用的机制在这组应用间进行通信。
可以看出微服务的特点是小而独立，轻量级通讯。正是因为小，所以每个微服务的逻辑相对简单，代码量也小很多，进而修复问题及修改变更会快很多；因为独立，每个微服务都可以单独进行修改，测试，部署，而多个微服务可以并行演进，从而可以缩短测试，部署和发布的时间；同样是因为独立，每个微服务都可以根据实际情况，单独的横向拓展；因为轻量级通讯，每个微服务才可以独立起来，贯彻高内聚低耦合的架构思想……
这些听起来似乎有些似曾相识，难道SOA不也是这样承诺的吗？
微服务的“前世”——SOA
时至今日SOA通常被看作是企业IT中的一个失败的运动，对于许多投资它的人来说，创伤仍然是新鲜的。那么微服务与SOA到底有哪些不同，为什么SOA失败了，但是微服务却大规模的流行了起来？
1. SOA没有大规模的，经过验证的，标准的落地实践，更多的是停留在理论层。同时很多SOA产品提供商也曲解了SOA的理念，以便更靠近自己的产品，使其大卖。而微服务的兴起却是依赖于大规模生产环境的考验，是实实在在可落地的，这增强了使用者的信心。比如Spring Cloud框架，是由Netflix公司进行开源，并且由Pivotal进行封装的微服务框架，经过了长时间的生产环境的验证；
2. 现时的IT环境已经发生巨变。正是由于敏捷开发管理，容器及容器云技术，DevOps等等方法，实践，工具，平台的不断成熟，微服务才可以如此迅速的发展起来。敏捷开发管理提供了一种应对需求快速变化的软件开发方法，顺带减少了交付过程中的一些浪费，容器及容器云技术解决了基础设施快速到位的问题，DevOps解决了持续集成，持续部署的问题。而微服务则是从应用架构角度解决了应用快速适应变化，高容错，横向拓展等问题。这四者互为补充，构建了一套完整的能够快速响应变化的IT整体环境。反观SOA的时代，没有“群雄”的支持，SOA也是想法虽好，却独力难支。
微服务的“今生”
以Spring Cloud为代表的微服务框架正在如火如荼的在企业IT架构中活跃着，而以Istio为代表的Service Mesh微服务架构正在悄然兴起。Service Mesh以更为合理的架构设计和更为简单使用方法吸引了众多的追随者。但是目前Service Mesh产品还没有大规模在生产环境上使用的案例，比如Istio也只发布了0.8版本，WeiBo Mesh，华为Mesher，蚂蚁金服的SOFA Mesh也都处于研发阶段等等。总的来说，Service Mesh前景美丽，但道路曲折。
最后附上自己整理的应用架构思想和微服务架构思想的演进路线，欢迎各位猛烈拍砖~~
