通过这几年在项目中实践微服务，为客户提供微服务咨询，我越来越发现所谓“微服务（Micro Service）”其实一点都不“微”！这非Martin Fowler定义之过。他所定义的概念，突出了设计每个独立服务时要分解的粒度，但对于整个架构风格而言，实践微服务并不如概念所表现的那样举重若轻，然后轻而易举。一个微服务从诞生到最后的消亡，经历了设计、开发、测试、上线、运行到下线贯穿始终的生命周期。每个环节都有方方面面的因素需要考量。诸如设计原则的遵守、通信机制的选择、数据一致性的保障、健康状态的监控与跟踪，乃至于服务的配置、测试与运维，更何况还需要对企业的组织结构进行改革，遵循康威定律组建团队使之与微服务架构风格相匹配。
我们，还能说微服务是小而美吗？
既然如此，为何还有这么多企业对其趋之若鹜呢？个人认为，微服务做的是结构与规模的权衡。当二者不可得兼时，选择降低规模以应对业务复杂度的增长，牺牲结构来换取对复杂系统的控制。观察前面提及的诸多考量要素，是否都属于技术实现的范畴？这就对了！对于软件系统的实现者而言，我们无法决定业务复杂度的增长，但却可以将技术复杂度掌控在自己的手心。因此，微服务利用“分而治之”的思想减小了系统的规模，使得每个微服务的开发者不用面对复杂的业务逻辑，即使业务发生了变化，在如此小规模的“微”服务中，我们也能轻松面对。——最坏的情况，不如重写一个微服务！
这种分解在带来规模减小的同时，引入的却是分布式系统固有的技术复杂度。这种复杂度依旧挑战着编程的极限，但对于未来，我们却不再是茫然不可知了。微服务将业务实现的难题转向了基础设施的难题，进而成为整个软件行业面对微服务的共同焦虑点。终于，我们能够抛开具体业务的束缚了！面对这共同的焦虑，一些技术先行者开发了公共的微服务平台与框架，致力于解决基础设施的问题，于是就有了Netflix OSS、Spring Cloud、Service Fabric、ServiceComb、Istio等微服务框架；而云端的PaaS与容器化技术又解决了服务部署、服务编排、服务监控等基础问题。面向业务的微服务开发者们，就可以面对真正的小而美的“微”服务了。
分解业务复杂度，控制技术复杂度，此之为业界拥抱微服务的根本原因。
分解业务复杂度，是服务设计要解决的问题；控制技术复杂度，则提升到系统工程的高度，需要考虑团队组织、框架选型、部署运维等微服务全生命周期的每个环节。幸运的是，王磊兄的这本《微服务架构与实践》全面地回答了这两方面的问题。我极为认同书中提到的“微服务生态系统”这一概念。以“生态系统”名之，就能够让大家在看到微服务之“微”的同时，还能重视微服务“不微”的另一面。面对微服务的应用开发人员，我们希望隐藏它“不微”的一面；然后将这背后的苦活累活脏活交给架构的设计者，微服务平台的实现者，让他们去构造和打磨内部精巧细微的零部件与支撑平台。
从“不微”进入到“微”，是从宏观世界进入微观世界，整个过程其实是一个艰巨的架构设计过程。无论是在新项目中拥抱微服务架构，还是将遗留的单块架构迁移到微服务架构，都需要慎重行之，在微服务的优势与不足中取得良好的平衡。To do or not to do，这是个问题。而王磊兄结合自己这数年来实践微服务架构的心得体会，总结了“微服务实施参考模型”，通过可以量化的适用性评估、成熟度参考与度量指标，让选择的难题迎刃而解。这是本书的一大创见！
从计算机的发展历史来看，微服务是一个新生产物，但它不是从石头缝里突然蹦出来的，它的设计思想其实是分布式系统与SOA的延续，同时又汲取了DevOps、持续集成、持续交付等工程实践，并借着云计算和容器化的春风开始了它的驰骋之旅。因此，要做好微服务架构，既需要在业务和技术方面钻研得够深，又需要涵盖整个生命周期的广博知识。专而且博，二者很难兼得，但本书内容恰恰在这两方面都得到了很好的体现。我想，这一方面得益于本书作为第二版，在前一版全面介绍微服务架构的基础之上，是一次体系化的精进，内容臻于炉火纯青；同时又有赖于王磊兄在ThoughtWorks与华为亲身经历的众多大型项目，收获了大量实践微服务架构的经验。
微服务是与时俱进的。从Martin Fowler提出“微服务”概念至今，不过三、四年时间，这其中已经诞生了多少“呼风唤雨”的平台和框架？在软件设计领域，实现技术瞬息万变，唯有设计思想方能历久弥新。幸运的是，本书既通过实战案例为你提供了微服务落地的参考；同时，又高屋建瓴地对微服务架构思想进行了全方位的梳理。我们常说鱼与熊掌二者不可兼得，本书却通过合理巧妙的章节分布与匠心独运的内容编排，同时兼顾了“微”与“不微”，专与博，变与不变，真可以说是一本“贪心”之作，但对于读者而言，不正是一壶可以贪杯的佳酿吗？
