译者序

自马丁·福勒（Martin Fowler）在2014年发表了以“微服务”为主题的文章后，微服务随之变得炙手可热。短短数年间，“微服务”已经成为一个大家所熟知的技术名词，受到无数人的追捧。在各大技术会议上，各大互联网企业也都纷纷分享自己在微服务实践方面的经验和总结，甚至于出现了跟风和言必称“微服务”“微服务嫉妒”（Microservice envy）的情况，仿佛设计架构上不是“微服务”风格的话，就在技术上有不足似的。人们的认识也不断变化，“Monolith First”“Microservice First”以及“Micro Frontends”都是人们认识不断深入的体现，乃至于偶尔媒体上出现哪家公司放弃了“微服务”的新闻报道或者“微服务之死”的讨论，都会成为热点。

最近看到这样的一个段子。

Q：大师，大师，微服务拆多了怎么办？

A：那就再合起来啊。

Q：那太没面子了啊。

A：你就说你已经跨域了微服务初级阶段，在做中台了。

其实“微服务”从来就不是“银弹”，也不可能成为“银弹”。通过将现有的单体应用或者业务领域进行拆分，分而治之来降低系统的复杂性和维护难度，这是一种很普遍的理念。随着单体应用越来越臃肿，业务和需求越来越复杂，微服务的出现也是行业发展到一定阶段的必然产物，每个微服务负责一块业务或技术能力，独立部署，独立维护和扩展，甚至于在某些情况下随着业务的变化，将某些微服务再进行合并，也并不是不可以的。

回到“微服务”和“中台”这两个概念，上面的段子漏洞百出，不值得讨论。微服务体现去中心化、天然分布式，与阿里的中台战略思想类似，是战略的具体实现方式之一，是连接业务架构和中台的一座桥梁；中台目前还更多停留在初级阶段，但微服务架构已经有了较为成熟的理论和方法论，能极大推动和提高中台战略的落地成功率。由此可见，现实并非上面段子那样简单粗暴的解释。

面对快速发展变化的IT行业，各种和微服务相关的技术和框架不断涌现，架构师和开发人员需要具备透过这些表象看清事物本源的能力。微服务架构不仅涉及架构设计和开发阶段，还包含了测试、部署以及运维阶段，是一个完整的生命周期。以往的许多图书要么过于理论化，要么过于偏向技术应用层面的实践，要么仅侧重于某一个微服务的某一个阶段。本书理论与实践相结合，不仅有理论介绍，也介绍了很多微服务架构生命周期中各个阶段的优秀设计模式和最佳实践，是非常难得的学习用书。

在我看来，微服务不会消亡，随着各种技术、框架和工具的丰富和强大，尤其是service mesh之类的技术的演进，未来也许微服务架构的许多内容会像空气那样无处不在但大家又不会感知到它的存在。到了那时，大家开发过程中可能不会意识到微服务的存在，但是微服务已经是架构血液的一部分。作为有追求的开发人员和架构师，很有必要了解微服务的点点滴滴。

早在本书英文版出版之前，我就联系杨海玲编辑询问翻译事宜，期望能参与到中文版的翻译工作中。非常感谢杨海玲编辑的认可，最终承担了该书的翻译工作。本来计划能在短期内完成翻译稿件，但由于翻译期间个人家庭和工作原因，导致交稿时间一直拖延，影响了中文版图书的出版进度，非常感谢吴晋瑜编辑在整个过程中的理解和支持，希望以后能有更好的合作。另外，还要感谢公司的其他编辑们，他们为保证本书的质量做出了大量的编辑和校正工作，在此深表谢意。

读者在阅读过程中，发现有任何问题、错误或不妥之处，请随时联系我（lizhe2004@163.com）或出版社，我们将及时改正。也非常欢迎大家对本书提出宝贵的意见和建议。

李哲