编辑推荐
业内专家联合力荐
让微服务落地，深入分析践行微服务的种种要点
深入阐述微服务架构体系的各种绝佳实践
名人推荐
微服务架构，虽然诞生时间不长，却已成为软件架构领域讨论的热点。微服务的概念看似简单，但涉及诸多方法API实践积累，这就是为什么有人说它非常好，但就是“玩不起”。随着微服务生态系统的日趋完善，微服务架构的讨论也从API接口、服务间通信、接口测试、基础设施自动化等，逐渐扩展到了API网关、微服务的注册与发现、Docker封装与部署、持续交付以及运维体系的优化等多方面。本书结合作者过去多年的实战经验，深入浅出地梳理了微服务构建过程中遇到的诸多挑战，并给出了切实可行的解决方案（如何使用Spring Boot构建服务、使用ZooKeeper注册服务，如何结合Docker封装服务和发布服务等），是一本能帮助读者立刻动手、落地微服务的好书。同时，作者从开发和运维两个角度入手，详细地剖析了微服务实施过程中，如何有效解决“最后一公里”的部署以及运维难题。纵览全书，说理清楚，图文并茂，理论结合实际，是一本非常用心，又注重实操的好书，对企业的微服务架构实施，具有很大的参考意义，相信企业的架构师、软件开发人员、运维人员读完这本书一定会受益匪浅。
——王磊，尚度元科技CTO，《微服务架构与实践》作者
本书以微服务的生命周期为主线，系统地介绍了微服务技术架构的选型，微服务的开发和测试，基于Docker容器的部署，以及基础设施自动化和持续交付等。围绕各个环节，给出了技术选型和详尽的使用说明。对于微服务初学者，是本难得的入门好书。
——李林锋，华为软件平台开放实验室资深架构师，《分布式服务框架原理与实践》和《Netty权威指南》作者
近年来，微服务俨然成为行业内广受关注的热点。不论是微服务的价值，还是微服务的阻碍，都是行业在架构技术选型中最为关心的前提。除此之外，技术的践行流程，对现有组织架构、软件模式的影响，都是决策者不敢忽视的要素。我很庆幸看到，国内能诞生这本微服务领域的巨著。本书从架构发展史的角度，阐述了微服务兴起的客观性与必然性；从技术的角度，深入分析了践行微服务的种种要点；更从实践的角度，通过案例事无巨细地帮助读者去体会、理解、掌握微服务。实属口区心沥血之作，极力推荐大家阅读。
——孙宏亮，DaoCloud技术合伙人，《Docker源码分析》作者
黄勇的这本书从微服务实操的角度，通过在微服务架构体系的不同关注点，选择多样而务实的技术栈，为大家全方位地阐述了微服务架构体系的各种实践，对微服务感兴趣的同学不容错过。
——王福强，挖财首席架构师，《Spring揭秘》和《Spring Boot揭秘》作者
软件开发从来没有银弹，微服务也不是。我认为微服务本质上是要解决一个可伸缩性的问题，以应对访问的增加、业API杂度的增加和开发团队人员的增加。黄勇在本书中详细解释了实践微服务必须要面对的架构模式，包括服务注册与发现、API网关、以及简单部署系统的搭建，并辅以样例代码，对于正面临可伸缩性问题的开发人员有很大的参考价值。
——许晓斌，阿里巴巴高级技术专家，《Maven实战》作者
作者简介
黄勇，现任特赞公司 CTO，曾任阿里巴巴公司系统架构师。对微服务架构与大数据技术有深入研究，具有丰富的网站架构设计经验与项目管理经验，擅长敏捷开发模式。国内开源软件推动者之一，活跃于“开源中国”社区网站，Smart 开源框架创始人，图书《架构探险：从零开始写Java Web框架》作者。热爱技术交流，乐于分享自己的工作经验与生活感悟。
目录
第1章 微服务架构设计概述
1.1 为什么需要微服务架构
1.1.1 传统应用架构的问题
1.1.2 如何解决传统应用架构的问题
1.1.3 传统应用架构还有哪些问题
1.2 微服务架构是什么
1.2.1 微服务架构概念
1.2.2 微服务交付流程
1.2.3 微服务开发规范
1.2.4 微服务架构模式
1.3 微服务架构有哪些特点和挑战
1.3.1 微服务架构的特点
1.3.2 微服务架构的挑战
1.4 如何搭建微服务架构
1.4.1 微服务架构图
1.4.2 微服务技术选型
1.5 本章小结
第2章 微服务开发框架
2.1 Spring Boot是什么
2.1.1 Spring Boot的由来
2.1.2 Spring Boot的特性
2.1.3 Spring Boot相关插件
2.1.4 Spring Boot的应用场景
2.2 如何使用Spring Boot框架
2.2.1 搭建Spring Boot开发框架
2.2.2 开发一个简单的Spring Boot应用程序
2.2.3 运行Spring Boot应用程序
2.3 Spring Boot生产级特性
2.3.1 端点
2.3.2 健康检查
2.3.3 应用基本信息
2.3.4 跨域
2.3.5 外部配置
2.3.6 远程监控
2.4 本章小结
第3章 微服务网关
3.1 Node.js是什么
3.1.1 Node.js快速入门
3.1.2 Node.js应用场景
3.2 如何使用Node.js
3.2.1 安装Node.js
3.2.2 使用Node.js开发Web应用
3.2.3 使用Express框架开发Web应用
3.2.4 搭建Node.js集群环境
3.3 使用Node.js搭建微服务网关
3.3.1 什么是微服务网关
3.3.2 使用Node.js实现反向代理
3.4 本章小结
第4章 微服务注册与发现
4.1 ZooKeeper是什么
4.1.1 ZooKeeper树状模型
4.1.2 ZooKeeper集群结构
4.2 如何使用ZooKeeper
4.2.1 运行ZooKeeper
4.2.2 搭建ZooKeeper集群环境
4.2.3 使用命令行客户端连接ZooKeeper
4.2.4 使用Java客户端连接ZooKeeper
4.2.5 使用Node.js客户端连接ZooKeeper
4.3 实现服务注册组件
4.3.1 设计服务注册表数据结构
4.3.2 搭建应用程序框架
4.3.3 定义服务注册表接口
4.3.4 使用ZooKeeper实现服务注册
4.3.5 服务注册模式
4.4 实现服务发现组件
4.4.1 定义服务发现策略
4.4.2 搭建应用程序框架
4.4.3 使用Node.js实现服务发现
4.4.4 服务发现优化方案
4.4.5 服务发现模式
4.5 本章小结
第5章 微服务封装
5.1 Docker是什么
5.1.1 Docker简介
5.1.2 虚拟机与Docker对比
5.1.3 Docker的特点
5.1.4 Docker系统架构
5.1.5 安装Docker
5.2 如何使用Docker
5.2.1 Docker镜像常用操作
5.2.2 Docker容器常用操作
5.2.3 Docker命令汇总
5.3 手工制作Java镜像
5.3.1 下载JDK
5.3.2 启动容器
5.3.3 提交镜像
5.3.4 验证镜像
5.4 使用Dockerfile构建镜像
5.4.1 了解Dockerfile基本结构
5.4.2 使用Dockerfile构建镜像
5.4.3 Dockerfile指令汇总
5.5 使用Docker Registry管理镜像
5.5.1 使用Docker Hub
5.5.2 搭建Docker Registry
5.6 SpringBoot与Docker整合
5.6.1 搭建Spring Boot应用程序框架
5.6.2 为Spring Boot应用添加Dockerfile
5.6.3 使用Maven构建Docker镜像
5.6.4 启动Spring Boot的Docker容器
5.6.5 调整Docker容器内存限制
5.7 本章小结
第6章 微服务部署
6.1 Jenkins是什么
6.1.1 Jenkins简介
6.1.2 自动化发布平台
6.1.3 安装Jenkins
6.2 搭建GitLab版本控制系统
6.2.1 GitLab简介
6.2.2 安装GitLab
6.2.3 将代码推送至GitLab中
6.3 搭建Jenkins持续集成系统
6.3.1 创建构建任务
6.3.2 手工执行构建
6.3.3 自动执行构建
6.4 使用Jenkins实现自动化发布
6.4.1 自动发布jar包
6.4.2 自动发布Docker容器
6.5 本章小结
序言
序一
微服务，应用开发的新起点
研究现在的软件体系，不难发现：现在的软件专家们仍需要与大量的需求、设计、代码的细节打交道。出于项目实施时间、投入资源等方面的限制，软件往往以实现若干具体的用户功能需求为目标。专家们没有时间，也没有精力去追求软件的美学目标。日复一日，随着用户功能需求的变化，软件项目成为大量代码的随机而无序的堆积，奇丑无比。许多功能成一旦完成项目，就恐避之不及，不愿再去碰自己几个月来夜以继日的劳动成果。
黄勇的《架构探险：轻量级微服务架构》一书，融合了软件设计的最新理念，系统性介绍了微服务的设计、开发、运维等各方面，书中不仅仅是技术的描述和讲解。看到黄勇在技术方面这么多年的不断积累和提炼，我很欣慰。
微服务的兴起和移动应用的快速发展相对应。移动应用的基本框架是事件和响应，用户在碎片化的时间和地点，按自己的节奏完成综合起来是一个复杂的事情。这不同于传统软件，往往是流程和复杂业务驱动的过程和算法。移动计算所需要的跨界沟通和协作，在传统应用架构中则很难实现，而这恰恰是微服务的优势所在。微服务从技术的视角，使用各种协议和框架，便于不同开发者软件碎片之间的协同工作。但是各种软件交互协议并不稀缺，总是不断地出现各种协议的标准。微服务的成功使用，需要注意微服务在软件重用方面的能力，正是这种能力，使得微服务的使用更加具有普遍的意义。不同于传统的构件或服务，微服务的调用参数接口具有更大的融合性和灵活性。微服务的调用，不需要拘泥于严格的数据类型，而是遵循更高层次的语法结构。特别是应用软件走向人工智能的时代，微服务将更深的演化带来更智能的微服务对接。微服务对于传统的过程式软件，是一个破坏性的改变。这一特征既给了微服务无限的想象空间，也给实施带来了很多挑战。并不是每个应用，特别是成熟领域的软件应用都适合微服务的改造。但是对于移动应用领域和跨应用跨企业的对接，是一个很必要的选择。
我早年写了一些关于 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 和“面向构件”方面的东西，有人问我：“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
业内专家联合力荐
让微服务落地，深入分析践行微服务的种种要点
深入阐述微服务架构体系的各种绝佳实践
名人推荐
微服务架构，虽然诞生时间不长，却已成为软件架构领域讨论的热点。微服务的概念看似简单，但涉及诸多方法API实践积累，这就是为什么有人说它非常好，但就是“玩不起”。随着微服务生态系统的日趋完善，微服务架构的讨论也从API接口、服务间通信、接口测试、基础设施自动化等，逐渐扩展到了API网关、微服务的注册与发现、Docker封装与部署、持续交付以及运维体系的优化等多方面。本书结合作者过去多年的实战经验，深入浅出地梳理了微服务构建过程中遇到的诸多挑战，并给出了切实可行的解决方案（如何使用Spring Boot构建服务、使用ZooKeeper注册服务，如何结合Docker封装服务和发布服务等），是一本能帮助读者立刻动手、落地微服务的好书。同时，作者从开发和运维两个角度入手，详细地剖析了微服务实施过程中，如何有效解决“最后一公里”的部署以及运维难题。纵览全书，说理清楚，图文并茂，理论结合实际，是一本非常用心，又注重实操的好书，对企业的微服务架构实施，具有很大的参考意义，相信企业的架构师、软件开发人员、运维人员读完这本书一定会受益匪浅。
——王磊，尚度元科技CTO，《微服务架构与实践》作者
本书以微服务的生命周期为主线，系统地介绍了微服务技术架构的选型，微服务的开发和测试，基于Docker容器的部署，以及基础设施自动化和持续交付等。围绕各个环节，给出了技术选型和详尽的使用说明。对于微服务初学者，是本难得的入门好书。
——李林锋，华为软件平台开放实验室资深架构师，《分布式服务框架原理与实践》和《Netty权威指南》作者
近年来，微服务俨然成为行业内广受关注的热点。不论是微服务的价值，还是微服务的阻碍，都是行业在架构技术选型中最为关心的前提。除此之外，技术的践行流程，对现有组织架构、软件模式的影响，都是决策者不敢忽视的要素。我很庆幸看到，国内能诞生这本微服务领域的巨著。本书从架构发展史的角度，阐述了微服务兴起的客观性与必然性；从技术的角度，深入分析了践行微服务的种种要点；更从实践的角度，通过案例事无巨细地帮助读者去体会、理解、掌握微服务。实属口区心沥血之作，极力推荐大家阅读。
——孙宏亮，DaoCloud技术合伙人，《Docker源码分析》作者
黄勇的这本书从微服务实操的角度，通过在微服务架构体系的不同关注点，选择多样而务实的技术栈，为大家全方位地阐述了微服务架构体系的各种实践，对微服务感兴趣的同学不容错过。
——王福强，挖财首席架构师，《Spring揭秘》和《Spring Boot揭秘》作者
软件开发从来没有银弹，微服务也不是。我认为微服务本质上是要解决一个可伸缩性的问题，以应对访问的增加、业API杂度的增加和开发团队人员的增加。黄勇在本书中详细解释了实践微服务必须要面对的架构模式，包括服务注册与发现、API网关、以及简单部署系统的搭建，并辅以样例代码，对于正面临可伸缩性问题的开发人员有很大的参考价值。
——许晓斌，阿里巴巴高级技术专家，《Maven实战》作者
作者简介
黄勇，现任特赞公司 CTO，曾任阿里巴巴公司系统架构师。对微服务架构与大数据技术有深入研究，具有丰富的网站架构设计经验与项目管理经验，擅长敏捷开发模式。国内开源软件推动者之一，活跃于“开源中国”社区网站，Smart 开源框架创始人，图书《架构探险：从零开始写Java Web框架》作者。热爱技术交流，乐于分享自己的工作经验与生活感悟。
目录
第1章 微服务架构设计概述
1.1 为什么需要微服务架构
1.1.1 传统应用架构的问题
1.1.2 如何解决传统应用架构的问题
1.1.3 传统应用架构还有哪些问题
1.2 微服务架构是什么
1.2.1 微服务架构概念
1.2.2 微服务交付流程
1.2.3 微服务开发规范
1.2.4 微服务架构模式
1.3 微服务架构有哪些特点和挑战
1.3.1 微服务架构的特点
1.3.2 微服务架构的挑战
1.4 如何搭建微服务架构
1.4.1 微服务架构图
1.4.2 微服务技术选型
1.5 本章小结
第2章 微服务开发框架
2.1 Spring Boot是什么
2.1.1 Spring Boot的由来
2.1.2 Spring Boot的特性
2.1.3 Spring Boot相关插件
2.1.4 Spring Boot的应用场景
2.2 如何使用Spring Boot框架
2.2.1 搭建Spring Boot开发框架
2.2.2 开发一个简单的Spring Boot应用程序
2.2.3 运行Spring Boot应用程序
2.3 Spring Boot生产级特性
2.3.1 端点
2.3.2 健康检查
2.3.3 应用基本信息
2.3.4 跨域
2.3.5 外部配置
2.3.6 远程监控
2.4 本章小结
第3章 微服务网关
3.1 Node.js是什么
3.1.1 Node.js快速入门
3.1.2 Node.js应用场景
3.2 如何使用Node.js
3.2.1 安装Node.js
3.2.2 使用Node.js开发Web应用
3.2.3 使用Express框架开发Web应用
3.2.4 搭建Node.js集群环境
3.3 使用Node.js搭建微服务网关
3.3.1 什么是微服务网关
3.3.2 使用Node.js实现反向代理
3.4 本章小结
第4章 微服务注册与发现
4.1 ZooKeeper是什么
4.1.1 ZooKeeper树状模型
4.1.2 ZooKeeper集群结构
4.2 如何使用ZooKeeper
4.2.1 运行ZooKeeper
4.2.2 搭建ZooKeeper集群环境
4.2.3 使用命令行客户端连接ZooKeeper
4.2.4 使用Java客户端连接ZooKeeper
4.2.5 使用Node.js客户端连接ZooKeeper
4.3 实现服务注册组件
4.3.1 设计服务注册表数据结构
4.3.2 搭建应用程序框架
4.3.3 定义服务注册表接口
4.3.4 使用ZooKeeper实现服务注册
4.3.5 服务注册模式
4.4 实现服务发现组件
4.4.1 定义服务发现策略
4.4.2 搭建应用程序框架
4.4.3 使用Node.js实现服务发现
4.4.4 服务发现优化方案
4.4.5 服务发现模式
4.5 本章小结
第5章 微服务封装
5.1 Docker是什么
5.1.1 Docker简介
5.1.2 虚拟机与Docker对比
5.1.3 Docker的特点
5.1.4 Docker系统架构
5.1.5 安装Docker
5.2 如何使用Docker
5.2.1 Docker镜像常用操作
5.2.2 Docker容器常用操作
5.2.3 Docker命令汇总
5.3 手工制作Java镜像
5.3.1 下载JDK
5.3.2 启动容器
5.3.3 提交镜像
5.3.4 验证镜像
5.4 使用Dockerfile构建镜像
5.4.1 了解Dockerfile基本结构
5.4.2 使用Dockerfile构建镜像
5.4.3 Dockerfile指令汇总
5.5 使用Docker Registry管理镜像
5.5.1 使用Docker Hub
5.5.2 搭建Docker Registry
5.6 SpringBoot与Docker整合
5.6.1 搭建Spring Boot应用程序框架
5.6.2 为Spring Boot应用添加Dockerfile
5.6.3 使用Maven构建Docker镜像
5.6.4 启动Spring Boot的Docker容器
5.6.5 调整Docker容器内存限制
5.7 本章小结
第6章 微服务部署
6.1 Jenkins是什么
6.1.1 Jenkins简介
6.1.2 自动化发布平台
6.1.3 安装Jenkins
6.2 搭建GitLab版本控制系统
6.2.1 GitLab简介
6.2.2 安装GitLab
6.2.3 将代码推送至GitLab中
6.3 搭建Jenkins持续集成系统
6.3.1 创建构建任务
6.3.2 手工执行构建
6.3.3 自动执行构建
6.4 使用Jenkins实现自动化发布
6.4.1 自动发布jar包
6.4.2 自动发布Docker容器
6.5 本章小结
序言
序一
微服务，应用开发的新起点
研究现在的软件体系，不难发现：现在的软件专家们仍需要与大量的需求、设计、代码的细节打交道。出于项目实施时间、投入资源等方面的限制，软件往往以实现若干具体的用户功能需求为目标。专家们没有时间，也没有精力去追求软件的美学目标。日复一日，随着用户功能需求的变化，软件项目成为大量代码的随机而无序的堆积，奇丑无比。许多功能成一旦完成项目，就恐避之不及，不愿再去碰自己几个月来夜以继日的劳动成果。
黄勇的《架构探险：轻量级微服务架构》一书，融合了软件设计的最新理念，系统性介绍了微服务的设计、开发、运维等各方面，书中不仅仅是技术的描述和讲解。看到黄勇在技术方面这么多年的不断积累和提炼，我很欣慰。
微服务的兴起和移动应用的快速发展相对应。移动应用的基本框架是事件和响应，用户在碎片化的时间和地点，按自己的节奏完成综合起来是一个复杂的事情。这不同于传统软件，往往是流程和复杂业务驱动的过程和算法。移动计算所需要的跨界沟通和协作，在传统应用架构中则很难实现，而这恰恰是微服务的优势所在。微服务从技术的视角，使用各种协议和框架，便于不同开发者软件碎片之间的协同工作。但是各种软件交互协议并不稀缺，总是不断地出现各种协议的标准。微服务的成功使用，需要注意微服务在软件重用方面的能力，正是这种能力，使得微服务的使用更加具有普遍的意义。不同于传统的构件或服务，微服务的调用参数接口具有更大的融合性和灵活性。微服务的调用，不需要拘泥于严格的数据类型，而是遵循更高层次的语法结构。特别是应用软件走向人工智能的时代，微服务将更深的演化带来更智能的微服务对接。微服务对于传统的过程式软件，是一个破坏性的改变。这一特征既给了微服务无限的想象空间，也给实施带来了很多挑战。并不是每个应用，特别是成熟领域的软件应用都适合微服务的改造。但是对于移动应用领域和跨应用跨企业的对接，是一个很必要的选择。
我早年写了一些关于 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 和“面向构件”方面的东西，有人问我：“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
| ISBN | 9787121298042 |
|---|---|
| 出版社 | 电子工业出版社 |
| 作者 | 黄勇 |
| 尺寸 | 16 |