业内专家联合力荐
让微服务落地，深入分析践行微服务的种种要点
深入阐述微服务架构体系的各种最佳实践

序一
微服务，应用开发的新起点


研究现在的软件体系，不难发现：现在的软件专家们仍需要与大量的需求、设计、代码的细节打交道。出于项目实施时间、投入资源等方面的限制，软件往往以实现若干具体的用户功能需求为目标。专家们没有时间，也没有精力去追求软件的美学目标。日复一日，随着用户功能需求的变化，软件项目成为大量代码的随机而无序的堆积，奇丑无比。许多功能成一旦完成项目，就恐避之不及，不愿再去碰自己几个月来夜以继日的劳动成果。
黄勇的《架构探险：轻量级微服务架构》一书，融合了软件设计的最新理念，系统性介绍了微服务的设计、开发、运维等各方面，书中不仅仅是技术的描述和讲解。看到黄勇在技术方面这么多年的不断积累和提炼，我很欣慰。
微服务的兴起和移动应用的快速发展相对应。移动应用的基本框架是事件和响应，用户在碎片化的时间和地点，按自己的节奏完成综合起来是一个复杂的事情。这不同于传统软件，往往是流程和复杂业务驱动的过程和算法。移动计算所需要的跨界沟通和协作，在传统应用架构中则很难实现，而这恰恰是微服务的优势所在。微服务从技术的视角，使用各种协议和框架，便于不同开发者软件碎片之间的协同工作。但是各种软件交互协议并不稀缺，总是不断地出现各种协议的标准。微服务的成功使用，需要注意微服务在软件重用方面的能力，正是这种能力，使得微服务的使用更加具有普遍的意义。不同于传统的构件或服务，微服务的调用参数接口具有更大的融合性和灵活性。微服务的调用，不需要拘泥于严格的数据类型，而是遵循更高层次的语法结构。特别是应用软件走向人工智能的时代，微服务将更深的演化带来更智能的微服务对接。微服务对于传统的过程式软件，是一个破坏性的改变。这一特征既给了微服务无限的想象空间，也给实施带来了很多挑战。并不是每个应用，特别是成熟领域的软件应用都适合微服务的改造。但是对于移动应用领域和跨应用跨企业的对接，是一个很必要的选择。
我早年写了一些关于 SOA 和“面向构件”方面的东西，有人问我：“SOA和微服务有何差异？”我认为：SOA 的核心还是企业级应用。最大的差异，是微服务对于调用参数的宏定义，语义的适应性，使得微服务的复用性大大提升。比较有意思的是，新的微服务调用参数体系，和普元EOS非常类同，15年前我们就是这样设计的。微服务是SOA后的一个突破性的东西，不是简单的落地，SOA 本身也有落地，比如普元的EOS就是SOA落地后的产品。SOA到微服务一方面是网络协议的提升，更加适应跨应用跨企业的服务调用。还有人问我：“构件和微服务到底有什么区别？”我认为：构件是装配、开发的视角，一台机器由一个个构件装配而成；服务是运行、传动的视角，能量从活塞到轮胎传播。微服务用代码来开发，但微服务可以当成一个构件装配到应用。两边视角不同，但是微服务给了软件模块更多生命力。构件是静态的，服务是动态的。
这本书对于微服务架构的介绍非常完整，如果你和你们的企业正在开发移动应用，或者对已有的应用正在规划架构性的重构，这本书很值得一读。

—黄柳青


序二
微服务，我们如何与你相处


微服务来了，有了“服务”这两个字，这注定又是个一说就明白、一举例就糊涂、一讨论就吵架的概念。微服务的出现有其必然的商业背景和架构哲学，如何更好地认识微服务的内涵、如臂使指地应用微服务架构，还是有着很多挑战的，这也许就是本书被命名为“架构探险”的原因。
企业数字化转型驱动架构升级
互联网经济深刻改变了我们身边的商业环境，消费者的生活方式日益数字化，人们可以在任何时间、任何地点利用线上、线下渠道体验无缝购物，运用社交媒体表达自我，企业也在运用多种技术手段，发挥数字化潜力，改善客户联系，促进企业业务模式的转型。Gartner认为，数字化就是把人、事、物和商业联系起来，建立新的商业模式。未来的企业都将是IT企业，IT将从后台走向前台，从ERP、CRM等内部流程优化为主的业务，逐步转向内外兼修的模式，从而实现商业创新。
这一变化要求IT架构更加灵活地与上下游企业协作，更加快速地响应客户的个性化需求，更加弹性地应对无时不在的客户请求并提供良好的客户体验，同时云计算、大数据等技术的出现也为上述改变提供了新的技术选择，我们正面临B/S多层架构出现后新的一次架构升级，而微服务架构就在这个架构升级过程中应运而生。
分而治之的哲学是微服务的理论基础
把大的问题分解为容易解决的小问题，找到小问题的解决办法，再来解决大问题，这就是分而治之的哲学。正如万事万物由分子、原子组成一样，软件也可以分解为基本单元，以这样的基本单元进行开发、测试、维护，是解决大规模系统建设的思路。分而治之首先要解决如何分的问题，企业软件的分法应该是以业务驱动的，而不是以技术驱动的，也就是分解为独立的业务逻辑，而这样的不可再分的业务逻辑就是微服务。
凡事有一利必有一弊，细分为微服务后，势必带来部署、测试、信息集成难度的提高，分而治之除了“分”，还需要“治”。传统恐龙型ERP是一个面向组织的软件，完备、复杂、响应变化慢，适合业务稳定的情况，而在数字化时代，客户个性化的要求让我们从这种面向组织的软件逐渐演变为面向个体的软件。例如，从前的EHR软件是为人力资源部门服务的，整体开发、整体实施，而现在我们会从个体的角度规划软件，可以先从招聘专员开始做一个面试管理的流程，逐步推出新的流程，完善现有的流程。这些面向个体的流程就是微应用，企业应用将由无数个微应用组成。微服务则是一个技术概念，能更好地解决微应用的技术实现问题，是一个事物的不同侧面，所谓“横看成岭侧成峰，远近高低各不同”，微服务和微应用是事物的一体两面。正因为微服务实际就是一个业务逻辑，因此做好微服务需要从微应用的维度考虑，将分解开的逻辑形成一个整体，要从多渠道接入、客户体验、数据管理、应用交付、运维全方位的视角考虑，这就是分而治之中实现“治”的体验，也是微服务架构需要解决的问题。
站在SOA的肩膀上践行微服务
微服务是一个新概念，但这绝不是一个全新架构，更不是一个包治百病的架构。由于有服务二字，很容易让人联想到面向服务架构（SOA），其实微服务架构属于应用技术架构，和以 B/S 为代表的三层架构相对应，强调将巨石型应用拆分为由微服务组成的应用，在数据上也视情况从集中的存储拆解为更小的存储单元。而SOA属于企业架构的范畴，从企业架构出发把业务分解为不同领域的服务，不同物理系统提供不同服务，注重系统之间通过服务互联互通的规范，对服务如何实现并不关注。因此，面向服务架构的服务应该是一个业务意义的服务，而微服务是系统中的技术服务，更关注服务的实现，虽然提供了业务意义的服务，但是不能混为一谈。微服务使用也不是无限度的，事实上由于数据一致性等问题的限制，不能无限度拆分微服务，可以把微服务分为系统对外提供的远程服务、系统内部的远程服务和系统内部的本地服务，显式声明、明确职责。事实上，在企业架构上使用 SOA 支撑业务，而在应用技术架构上使用微服务架构，是一个合适的选择。
黄柳青博士是我和黄勇共同的导师，他在2004年所著的《软件的涅槃》一书中指出：“互联网时代的企业应用定义，正发生革命性的变化…横向的部门互动、实时的企业间互动、多样的交互渠道、灵活的业务规则，使得原有意义上的独立应用不复存在…对软件设计者来说，能直观地分割并具有最小内部耦合的软件结构是简约之美…美的软件是软件企业与软件开发者的终极目标”，那时候他把这种全新的软件生产模式称为“面向构件”。回头看来，微服务正是“面向构件”在数字化时代的解读，用微服务架构实现软件之美，加速企业数字化转型。
—焦烈焱，普元CTO
前言


微服务是近年来备受关注的话题，它的出现让我们想起了十年前的 SOA（Service-Oriented Architecture，面向服务架构），但它比传统的 SOA 更容易理解，也更容易实践，它将“面向服务”的思想做得更加彻底。
当国外一些知名技术公司成功实践了微服务以后，这股热潮就吹遍了国内的大街小巷，大家街头巷尾都在聊微服务，对它众说纷纭且褒贬不一。有人说它非常好，但就是“玩不起”，为何会这样呢？
我们不妨带着这个问题来简单介绍一下，究竟什么才是微服务。
微服务是一种分布式系统架构，它建议我们将业务切分为更加细粒度的服务，并使每个服务的责任单一且可独立部署，服务内部高内聚，隐含内部细节，服务之间低耦合，彼此相互隔离。此外，我们根据面向服务的业务领域来建模，对外提供统一的 API 接口。微服务的思想不只是停留在开发阶段，它贯穿于设计、开发、测试、部署、运维等软件生命周期阶段。
可见，我们提到的微服务，实际上是一种架构思想，我们不妨称它为“微服务架构”。
微服务架构看起来如此之好，我们真的就需要它吗？
微服务架构建议我们按照业务来切分服务，我们完全可以选择最合适的技术来实现具体的服务，只需确保对外提供的 API 接口保持一致即可，也就是说，微服务架构使我们技术选型的自由度更加宽广了。既然系统可拆分为多个服务，这样非常有利于我们对每个服务进行监控，可不断收集每个服务的性能指标数据，当某个服务出现性能瓶颈时，会发出预警，我们可随时水平地扩展该服务，以支撑更大的流量，而不至于复制整个系统。由于服务之间彼此隔离，相互之间不会产生影响，因此我们可借助技术的手段来实现自动化部署，这会使我们的部署过程变得更加高效。
其实微服务架构的优点数不胜数，但是大家可能还是不敢用，因为它对我们的技术要求具有一定的挑战。比如，我们需要一个自动化部署系统，也需要解决分布式系统带来的一系列问题，还需要服务之间能做到彼此隔离且互不影响，同时还不能影响通信过程中所带来的性能开销。因此很多人认为，只有大公司或强悍的技术团队才能玩得起微服务架构，自己只能“远观”却不能“近玩”。甚至还有人认为，微服务架构实际上就是以前谈论多年而难以落地的 SOA。
实际上，我们认为微服务架构的本质仍然符合 SOA 思想，只不过它比 SOA 更容易落地。为了证明这件事情，我们经过了大量的实践，借助了许多优秀的开源技术，搭建了一款“轻量级微服务架构”。实践证明，该架构不仅可以适应大中型公司的业务变化，还能满足中小型公司的快速增长。我们真心地希望这款轻量级微服务架构能够帮助更多的技术爱好者以及更多的技术团队，顺利地走出技术困境，以全新的视角去迎接新的挑战。
不得不提醒大家的是：微服务并不是万灵丹！它不能包治百病，我们更不要为了微服务而去微服务。而是需要根据自身的情况，灵活地选择最合适的技术，通过技术的手段实现更高的目标。
为什么写这本书？
我一直很关注服务化方面的技术，记得在 2014 年，我偶然发现国外技术博客中有人在写关于“微服务”方面的概念与技术。坦白地讲，当我第一次看到微服务时，并没有对它产生浓厚的兴趣，我当时认为微服务是笨重的，它和传统的 SOA 没有太大的区别，同样都是服务化，只不过微服务更加细粒度而已。直到 Docker 容器技术逐步成熟起来，越来越多的人开始使用 Docker 来封装应用程序，并借助 Docker 技术让软件交付变得更加灵活而高效，这让我不由地对微服务的未来产生了强烈的期待，我坚信微服务将伴随着 Docker 技术成为未来软件开发与运维的核心武器。
我开始疯狂地学习微服务，研究它的各种架构模式与应用领域，开始自己动手做一些练习，并在公司内部大力推广这种新架构。在实践中，我获得了一点收获，曾在一些技术大会与企业内训中讲过微服务的原理与实践。我发现一个问题，虽然大家对微服务都非常关注，但往往却不知应该如何开始，应该使用哪些技术来搭建微服务架构，以及在实践中应该如何避免掉进坑里。甚至有些人还认为微服务只是大公司才玩得起的东西，因为它需要借助像 SOA 那样重量级的基础设施，需要付出大量的成本，但收益却不一定。其实，我想告诉大家的是，微服务架构并非这样，它应该是轻量级的，它应该是很容易上手的，它应该是任何公司想用就敢用的。虽然国内外已经有几本关于微服务方面的好书了，但我仍然希望这本书能为大家在微服务实践方面带来微薄的价值。
我们可以把微服务架构想象成海面上的一座冰山，看得见的部分是开发，看不见的部分是运维，一个好的微服务架构需要同时关注开发和运维两个方面。本系列书分上下两册，上册偏开发，下册偏运维。
您适合看这本书吗？
如果您还没听说过微服务，或者您听说了但不知道它究竟是什么，或者您正在尝试微服务的实践，那么这本书就非常适合您。不管您是一名开发人员还是一名运维人员，如果您向往成为一名优秀的微服务架构师，那么这本书更加值得您反复阅读和实践。
本书是如何组织的？
第1章：微服务架构设计概述。
从为什么需要微服务架构开始讲起，接着描述微服务架构是什么，以及微服务架构有哪些特点，最后以如何搭建微服务架构来结束本章。本章是全书的概述，从一个宏观的视角来讲解微服务，为后续章节搭建了一个骨架。
第2章：微服务开发框架。
本章我们将使用流行的 Spring Boot 来搭建微服务开发框架，对 Spring Boot 是什么，以及如何使用 Spring Boot 都做了描述，此外还对 Spring Boot 的重要产品级特性做了相关介绍。通过学习本章，大家可掌握 Spring Boot 的基本使用方法，并具备开发微服务接口的技能。
第3章：微服务网关。
本章我们将学习 Node.js 技术，描述 Node.js 是什么，以及如何使用 Node.js，此外还对 Node.js 的重要高级特性做了补充。最后我们将使用 Node.js 搭建一个微服务网关基础框架，后续章节会对此框架进行扩展。
第4章：微服务注册与发现。
本章我们将学习 ZooKeeper 框架，从认识 ZooKeeper 开始，到如何使用 ZooKeeper。最后我们将使用 ZooKeeper 实现一个简单的服务注册组件，并结合第3章中介绍的微服务网关框架，使用 Node.js 实现一个服务发现组件。
第5章：微服务封装。
本章我们将学习 Docker 技术，从了解 Docker 是什么开始，到如何使用 Docker，并通过手工和Dockerfile 的方式构建 Docker 镜像，此外还会介绍 Docker Registry 的使用方法，最后将以 Spring Boot 与 Docker 做一个整合来结束本章。通过学习本章，大家可熟练使用 Docker，为后续自动化运维提供基础。
第6章：微服务部署。
本章是上册的最后一章，我们将使用 Gitlab 管理项目源码，使用 Jenkins 搭建持续集成系统，最后基于 Jenkins + Gitlab + Docker 搭建一款微服务的自动化部署平台。通过学习本章，大家可将开发与部署更加高效地衔接起来。
我要致谢的人
我要把这本书送给我的女儿，虽然她根本就看不懂，因为她只有三岁。记得在她刚出生那年，我开始写技术博客；在她一岁那年，我开始做开源项目；在她两岁那年，我开始写自己的第一本书；在她三岁之时，这本书出版了。为了自己的事业，我借用了陪伴她成长的时间，这个时间是我这辈子都无法偿还给她的，希望她长大后能看到我送给她的这本书，或许她会理解我现在所做的一切。
我最想感谢的人还是我的妻子，她为了料理家务和照顾女儿，选择放弃自己的事业，全力支持我的事业，这种“放弃自己，成全他人”的精神，我是无法做到的。我有这样的好妻子，让我感到无比骄傲，同时我也需要给自己更高的目标，回报她对我的付出。
十年前我离开自己的家乡，独自来到上海打拼，这些年很少陪伴在自己父母的身边，因为工作太忙而遗忘了对父母的问候，我很愧疚自己所做的一切。感谢我的父母对我的无私付出，以及对我事业的认可与鼓励，希望他们看到这本书后能为我感到高兴。
感谢与我一起创业的伙伴们，大家能在一起共事是一种缘分，他们在工作上给我提供了许多帮助，和他们一起工作是我最开心的事情，我也能感受到自己在成长。他们还为本书提供了专业的建议，以及为本书提供了大量宝贵的实践经验。
感谢电子工业出版社博文视点的陈晓猛编辑，在写作过程中晓猛多次鼓励我，他曾说“写书就是登山”，每当我写不动了，想放弃了，他就会鼓励我“快到山顶了”，他无形中成为了我的“鼓励师”，让我顺利地写完了这本书。
感谢为这本书做评审的专家们，他们的专业态度让我非常感动。为了给读者提供更多的价值，他们给我提供了大量的建议，这些建议对我的帮助非常大，让我在后续写作道路上更有经验了。
感谢一直支持我的读者们，没有你们一路的陪伴，我会失去写作的动力和方向。
最后我想说的是：我并不是微服务架构专家，我只是一名微服务架构的实践者，只想把自己实践的经验分享给大家。由于本人学识有限，难免会有不足之处，还请读者不吝赐教。

黄勇
2016年7月27日于上海