3.4 关于微服务
谈到分布式服务框架，不得不提到近两年越来越热门的“微服务”。如今关于“微服务”的文章和讨论越来越多，随着越来越多的互联网公司基于“微服务”架构构建了自身核心业务平台后，“微服务”也获得了越来越多技术人员的肯定。反观阿里巴巴的共享服务体系建设的过程以及现状，会发现整个过程和目前运行的机制与微服务典型特征不谋而合，所以说2009年阿里巴巴开始构建的共享服务体系应该算得上是微服务实践的先驱，经过7年多的实践探索和演变，绝对称得上是“微服务”架构在大型互联网公司中的最佳实践。
但随着“微服务”理念的越来越深入人心，加上最近几年基于容器化技术Docker的不断盛行，笔者看到一些文章和媒体将这两个热点的领域关联到了一起，甚至划上了等号，这就很有点误导的嫌疑。在本章节中让我们一起基于微服务架构的典型特征逐一进行剖析，让更多计划构建微服务应用或架构的读者能更清晰、准确地看到“微服务”建设的本质。
对于微服务每个人都有自己不同的理解，我个人比较赞同Martin Fowler对于微服务架构的典型特征的描述：
分布式服务组成的系统。
按照业务而不是技术来划分组织。
做有生命的产品而不是项目。
智能化服务端点与傻瓜式服务编排。
自动化运维。
系统容错。
服务快速演化。
从本质上来说，“微服务”是SOA的一种演变后的形态，与SOA的方法和原则没有本质上的差别。将传统SOA与微服务的典型特征做一个对比解读，会发现其中鲜明的差异：
分布式服务组成的系统。意味着各个系统都将会是有多个分布式的服务组成，而不是传统SOA架构中基于“中心化”企业服务总线（ESB）的方式构建服务架构，更多是采用系统提供服务的方式实现系统间的打通和交互。
按照业务而不是技术来划分组织以及做有生命的产品而不是项目。前文所提及的，传统SOA实施的方式是以项目的方式实施，而不是以做产品的方式让服务在业务发展过程中快速演化。
智能化服务端点与傻瓜式服务编排。更加强调了能力向服务端的迁移，而不是像传统ESB的方式，将整体服务架构中的所有核心能力都运行在ESB上。
自动化运维和系统容错。这两点则是在微服务架构建设后，对于整体服务的运维管控和平台高可用性和稳定性方面提出了更高的要求。
不得不承认，随着Docker容器技术的不断成熟和完善，相比于虚拟机，容器技术的主要差异化优势在于，能够包装，便于移植，为适合用途而随需创建，因此减少了资源占用空间，缩短了启动时间，具有可重复性，提高了服务器的资源利用率，更好地集成到整个开发生态系统（比如持续集成/持续交付生命周期）。所以在企业的应用达到一定规模后，通过容器化技术，确实能大大提升运维效率，减少服务器资源的浪费，所以也看到越来越多应用集群规模比较大的互联网公司采用Docker的容器技术逐步改造原来基于虚拟机模式的基础架构，包括阿里巴巴近两年也投入了大量的资源进行这方面的改造。
笔者认为“微服务”中的这个“微”字给很多人带来了很多误解。从字面意思上，“微”会让人联想到一个微服务就应该是功能足够单一，甚至出现一个服务的实现可能只需要几十或者上百行代码的说法，这应该是最误导人的观点。从技术角度出发，确实可以通过简短的代码实现功能单一的服务，但从一个整体架构考虑，如果是以这样的方式实现各个微服务，则在整个服务体系范畴当中包含太多功能边界，那么对于服务运营的分工和边界就很难界定，给服务接下来的持续运营和维护带来困扰；另外拆分过于细化的服务，势必将带来大量无谓的分布式事务调用，给业务的实现带来额外的工作量和风险。
回到Docker这个问题，正因为有了“微服务”中所谓“微”服务的说法，那如何对这些微服务进行快速的部署、发布，更高效的利用服务计算资源，就给了容器技术爱好者借题发挥的空间，开始宣传Docker是实现微服务的解决方案的说法。
从技术角度，Docker完全有能力而且适合微服务体系中给服务提供实际的运行容器以及进行部署运维的平台，但Docker本身提供的核心能力还只是在计算资源层面，对于微服务架构所需的应用服务层面还存在着不小的空缺，构建企业微服务架构的建设过程中一定会遇到本书中阿里巴巴构建共享服务体系过程中所遇到的以下一系列问题，而这些远不是单单的Docker平台能解决的问题：
微服务化的应用架构如何进行有效的服务管控。在分布式服务体系下，服务链路跟踪、链路分析、实时业务指标的监控等问题，也都是实现微服务架构时一定会面临的问题，扩大到更大范围就是整体服务平台的管控能力。简单说，微服务架构的落地将会给企业的运维团队带来前所未有的挑战，原有的运维方式和工具可能在今天微服务的时代都显得力不从心。
分布式事务难题。服务化后的应用如何解决随之而来的分布式事务问题，一定需要针对业务的需求在事务一致性和性能间做好平衡，一套稳定、成熟的分布式事务解决方案也是构建微服务架构首先要思考好的技术方向问题。
自动化运维和平台稳定性。微服务架构相比之前独立应用的部署方式，从服务器的数量以及服务交互复杂程度都上升到一个新的等级，原有运维平台和工具是否能高效支撑微服务架构的运维也需要好好斟酌。
微服务带来了服务间错综复杂的调用关系，如何能在大促、秒杀、机器故障时，这些服务都能稳定提供服务？这对于整个平台的高可用性和稳定性提出了非常高的要求。
微服务的服务设计。微服务中服务边界的划分一定是从业务的维度，以什么样的服务颗粒度定义服务？以什么样数据模型支撑服务能力的线性扩展？如何保持设计出的服务具有很好的业务前瞻性？在高效满足现有业务需求的前提下，还能保持整个服务能力的通用性，为接下来其他业务的服务接入提供业务的扩展能力？这些问题都是微服务架构在落地过程中，实施团队都将面临的问题。
原有组织架构是否满足微服务架构持续发展的需要。服务强调持续的演变，需要组建对应的组织或者对现有的组织架构进行调整，围绕以服务为中心的持续运营，这对于很多企业原有的信息中心架构是一个不大的冲击和改变。
总结来说，微服务不是“免费的午餐”，当越来越多人意识到这种架构给业务响应和创新带来高效助推能力的时候，也需要深刻了解微服务架构建设中和建设后所将面临的一系列问题，这需要一个专业的团队和平台来保障微服务架构的成功落地。阿里巴巴过去几年从原有传统应用架构转变为今天共享服务体系的架构，本质上是微服务架构建设的过程，这不仅仅是技术上的改变，也是业务不断演变的结果。正所谓“罗马不是一天建成的”，企业如果要构建微服务体系架构，不要期望靠一个项目就能建立起来，需要多一份耐心，通过服务能力在业务发展过程中的不断沉淀，当业务的能力沉淀到一个阶段后，才能真正感受到微服务架构给企业的业务发展带来的长远价值，而这份价值体现出来时，会给企业带来业务高速发展的翅膀，真正让企业的业务发展飞得更快、飞得更远。
