详情
描述分布式架构组成及基础版本实现原理，介绍Dubbo与Spring Cloud主流分布式框架。
以实际项目需求为出发点，使用Spring Cloud（为主）与Dubbo解决服务发现与注册、服务网关、restful、数据库操作、缓存、消息队列、日志、全文检索服务、服务调用、错误处理、服务管理、表单验证等。
书名：微服务分布式构架开发实战
ISBN：978-7-115-47558-9
本书由人民邮电出版社发行数字版。版权所有，侵权必究。
您购买的人民邮电出版社电子书仅供您个人使用，未经授权，不得以任何方式复制和传播本书内容。
我们愿意相信读者具有这样的良知和觉悟，与我们共同保护知识产权。
如果购买者有侵权行为，我们可能对该用户实施包括但不限于关闭该帐号等维权措施，并可能追究法律责任。
• 著 龚 鹏
责任编辑 赵 轩
• 人民邮电出版社出版发行 北京市丰台区成寿寺路11号
邮编 100164 电子邮件 315@ptpress.com.cn
• 读者服务热线：(010)81055410
反盗版热线：(010)81055315
随着第三方框架的逐渐完善，实施微服务架构的开发成本越来越低，分布式架构成为主流势不可挡。一个完善的架构或系统中包含了许多的知识点，而每一个知识点则又可以引出非常多的内容，过度地专注于细节反而会拖慢达成目标的步伐。为了更快地实施微服务，本书基于开源且稳定的第三方工具，介绍如何构建一个庞大且复杂的分布式系统，用于满足项目中的实际需求。
每一个工具库为了适应更丰富的使用场景，通常都会把部分参数以配置文件的方式暴露出来，同时提供用于开发环境的默认配置。本书基于快速使用为主线，尽可能多地讲解配置参数的意义及它们之间的关系，帮助读者在掌握足够多的知识点后，建立起对微服务分布式架构的认知，以便为探求更深层次的知识点做好铺垫。
本书适合Java工程师、初级架构师、大中专院校相关专业师生、Java培训班学员及独立开发者与自学读者使用。
龚鹏同学的这本书全面覆盖了微服务的细分领域，以一线实战视角详述了如何实现微服务。一方面，读者可以通过本书拓宽技术视野，另一方面，读者也可以从其中的一章深入了解一个细分领域的微服务实践。
在阿里巴巴的生态中，微服务逐渐成为主要的服务形态，伴随着容器化的日臻成熟，大量的分布式、领域驱动设计的微服务被快速开发和部署，服务间呈现出搭积木的能力，使不同的业务通过重新组合数个微服务，就能实现新的业务场景。借助成熟的底层集团中间件，天然地支持微服务所需的动态扩缩、服务发现、全链路日志分析等能力。以阿里巴巴达摩院语音对话平台为例，对话服务、理解服务、问答服务，以及对话管理平台都是基于SpringBoot和Docker技术栈的。
希望读者能够通过本书的指引，在自己的工作和学习领域，快速并逐渐深入地建立起自己的微服务。
韩陆
《Java RESTful Web Service实战》作者
达摩院语音对话平台负责人
在当下的互联网世界里，系统开发既简单又困难。说它简单，是因为各技术社区的贡献及各框架的完善，使整个生态越来越丰富，绝大多数的需求都可以使用现有的库实现（不用重新发明“轮子”），并且现在很多的库都非常注重使用体验，以快速实现为目标，通过少量的配置及代码便可集成使用。但合理地编排这些库以构建一个高效、稳健、灵活的系统，并不是一件容易的事，人们一般将专精此道的人称为架构师。
一个完善可靠的微服务分布式架构需要解决众多的问题，我们可以用多种方法去解决这些问题，但刚开始接触时很难确定哪种方法是最优方案。在不确定并且刚接触如此庞大的架构时，选择信任、成熟且活跃的框架及第三方库提供的解决方案显然是明智之举。当建立起对微服务分布式架构的认知后，再重新回归最初的问题逐步审视并深入，最终形成属于自己的方案。
以往的图书大多只针对微服务分布式架构自身的知识点讲解，周边的相关知识点并未涉及，在进行项目实践时，最终效果则根据读者自身的知识储备而定。
本书并没有过多地探讨理论性的内容，而是基于现有成熟框架，围绕实际项目中遇见的具体需求，以微服务分布式架构的角度去逐一分解并且实现这些需求。掌握这些知识的读者，完全有能力快速搭建出可靠、高效、灵活的微服务分布式架构。
借助于现有框架进行微服务分布式架构实践的成本越来越低，并且这种形式正在逐渐成为主流架构。在进行框架及第三方库的选择时，也同样紧跟行业动向。
本书中的每一个示例都尽量用最少的代码和最快的方式解决具体的问题，为读者呈现复杂系统中简单的一面，其目的是快速接受并理解各知识点在微服务分布式架构中所处的位置及其相互关系。
Java工程师
初级架构师
独立开发者与自学读者
高校相关专业师生
Java培训班学员
技术服务于商业，尽量避免陷入技术细节的漩涡中，不要为了技术而技术。在进入学习状态之前，根据书中的章节与自己的经验明确学习目标，不断地提出问题并验证，最终找出答案。
面对一个复杂架构体系，从简单的知识点入手逐个攻破，用小成就感驱动自己最终完成设定的计划。
学习从来都不是一件容易的事，从学习ABC到写出自己的第一篇文章，从建立账号到超越第一个BOSS或者赢得第一场胜利，这之间的过程都是学习，都需要投入大量的时间和精力。如果你想要做出心目中理想的网站，或者将其作为自己赖以谋生的技能，坚持下去，你才能够做到。
互联网技术的优势是，当你遇到问题时，往往可以在互联网上寻求答案。互联网行业的大牛同样活跃在互联网上，找到他们，向他们学习。订阅公众号或者相关博客，积极了解行业发展和最新动向。这是其他学科无法比拟的优势。
在本书写作出版过程中，无论是作者还是编辑，都希望本书能够尽善尽美。如果您发现了本书的不足或错漏之处，欢迎您不吝赐教，帮助我们改进提升本书的内容，您可以通过以下方式联系我们。
我们为本书专门提供了一个QQ交流群（群号259280854），读者不仅可以在此向本书作者反馈建议，还能和其他读者共同交流，一起成长。
如果您有任何问题，都可以直接与作者联系，电子邮件地址为gongroc@outlook.com。我会尽快与您联系，解答您的疑问。
在异步社区http://www.epubit.com.cn/中搜索到本书页面，您便可以下载本书相关素材，还可以提交本书勘误。勘误被确认后，我们会向您提供积分奖励，这些积分可以在社区使用，如购书优惠、换领样书。
1.1 什么是微服务架构
1.2 垂直应用与微服务
1.3 实现一个最简单的微服务框架
1.4 主流微服务框架介绍
随着用户需求个性化、产品生命周期变短，微服务架构是未来软件架构朝着灵活性、扩展性、伸缩性以及高可用性发展的必然方向。这里主要将对比传统的垂直应用与分布式微服务应用之间的区别。
微服务是一种软件架构风格，目标是将一个复杂的应用拆分成多个服务模块，每个模块专注单一业务功能对外提供服务，并可以独立编译及部署，同时各模块间互相通信彼此协作，组合为整体对外提供完整服务。
微服务架构就像是活字印刷术，每个文字模都可以看成是一个微服务，它可以独立地提供印刷服务，又可以将模块之间组合，最终形成一篇完整文章提供更为复杂的印刷服务。
由于每个模块都独立部署，各自拥有互不干扰的内存空间，模块之间无法直接调用，所以需要借助RPC（远程过程调用协议）或HTTP协议让各个模块之间传递通信报文及交换数据，实现远程调用，整个通信管理的过程也是微服务架构重要的组成部分。
MVC模式构建的垂直应用非常适合项目初期，使用其能够方便地进行开发、部署、测试，但随着业务的发展与访问量的增加，垂直应用的问题也随之暴露出来，而微服务架构可以很好地解决这些问题。
垂直应用里，大部分逻辑都部署在一个集中化、单一的环境或服务器中运行。垂直应用程序通常很大，由一个大型团队或多个团队维护。庞大的代码库可能给希望熟悉代码的开发人员增加学习成本，还会让应用程序开发过程中使用的开发环境工具和运行容器不堪重负，最终导致开发效率降低，可能会阻止对执行更改的尝试。
微服务架构将这个庞大并且复杂的应用拆分成多个逻辑简单且独立的小应用，每个小应用交由不同的团队或开发人员维护，彼此之间互不干扰，通过标准接口互相通信。对于希望熟悉代码的开发人员来说只需掌握他所负责的应用即可，这样做的好处是简单、快速、逻辑清晰。
垂直应用需要处理一个庞大的应用程序，编译、部署需要花费很长时间，一个小的修改就可能导致重新构建整个项目。
微服务架构中对其中某一个服务进行修改，只需重新编译、部署被改动的服务模块。
垂直应用里，当请求量过大导致单台服务器无法支撑时，一般会将垂直应用部署在多台服务器形成服务集群，并通过反向代理实现负载均衡。集群中的每个服务必须部署完整的应用，但在实际业务需求中仅有部分功能使用频繁，但这种架构必须为不常用的功能分配计算资源。
微服务将提供功能的各服务拆分为多个服务模块，它具有天生的集群属性，能够轻松地根据用量部署。
例如系统中的消息功能使用频率占了整个系统的90%，而密码找回功能则只占到2%。为了分解消息功能的压力，以传统负载均衡的方式进行集群化时，每个服务必须为使用量只有2%的密码找回功能分配资源，这无疑造成了浪费。
在微服务架构中，消息功能使用率占据90%，则将消息模块多部署几个实例形成集群，而密码找回功能所在的用户模块只部署一个就可以了。
垂直应用中如果有一个小的问题，就可能使整个系统崩溃。
微服务所拆分出的各个模块中，由于模块之间的耦合度很低，当发生问题时影响范围被固定在该模块本身，整个系统依然健全。
基本工作流程如下。
① 客户端发起调用请求。
② 将调用的内容序列化后通过网络发给服务端。
③ 服务端接收到调用请求，执行具体服务并获得结果。
④ 将结果序列化后通过网络返回给客户端。
在发起远程调用时，需要基于接口（Interface）来约定客户端与服务端所调用服务的具体内容。为了方便管理依赖关系，这里使用Maven构建应用并编写一些接口，以提供给客户端与服务端使用。
当然也可以使用普通的Java应用来实现此简单微服务框架，只需将该应用编译后的jar包提供给后续的服务端与客户端即可。
groupId：org.book
artifactId：rpc-interface
version：0.0.1-SNAPSHOT
packaging：jar编写接口。
public interface HelloService {
public String hello(String name);
}新建用于提供服务的Maven应用，并引入刚编写的接口应用依赖。
groupId：org.book
artifactId：rpc-server
version：0.0.1-SNAPSHOT
packaging：jar① 在pom.xml文件中引入依赖。
<dependency>
<groupId>org.book</groupId>
<artifactId>rpc-interface</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>② 实现服务接口。
public class HelloServiceImple implements HelloService {
public String hello(String name) {
System.out.println("收到消息：" + name);
return "你好：" + name;
}
}③ 编写监听服务类。
public class Server {
private static ExecutorService executor = Executors.newFixedThreadPool(10);
private static final HashMap<String, Class> serviceRegistry = new HashMap<String, Class>();
public void register(Class serviceInterface, Class impl) {
//注册服务
serviceRegistry.put(serviceInterface.getName(), impl);
}
public void start(int port) throws IOException {
final ServerSocket server = new ServerSocket();
server.bind(new InetSocketAddress(port));
System.out.println("服务已启动");
while (true) {
executor.execute(new Runnable() {
public void run() {
Socket socket = null;
ObjectInputStream input = null;
ObjectOutputStream output = null;
try {
socket = server.accept();
// 接收到服务调用请求，将码流反序列化定位具体服务
input = new ObjectInputStream(socket.getInputStream());
String serviceName = input.readUTF();
String methodName = input.readUTF();
Class<?>[] parameterTypes = (Class<?>[]) input.readObject();
Object[] arguments = (Object[]) input.readObject();
// 在服务注册表中根据调用的服务获取到具体的实现类
Class serviceClass = serviceRegistry.get(serviceName);
if (serviceClass == null) {
throw new ClassNotFoundException(serviceName + " 未找到");
}
Method method = serviceClass.getMethod(methodName, parameterTypes);
// 调用获取结果
Object result = method.invoke(serviceClass.newInstance(), arguments);
// 将结果序列化后发送回客户端
output = new ObjectOutputStream(socket.getOutputStream());
output.writeObject(result);
} catch (Exception e) {
e.printStackTrace();
} finally {
// 关闭资源
try {
if (socket != null) socket.close();
if (input == null) input.close();
if (output == null) output.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
});
}
}
}提供一个数组保存所注册的服务接口及实现类。
启动一个阻塞式的Socket服务用于等待客户端发起的调用请求，当收到请求后将码流反序列化成对象，并根据接口从注册列表中寻找具体实现类，最终通过反射的方式调用该实现类返回结果。
④ 注册服务并启动服务端。
public class App {
public static void main(String[] args) throws IOException {
Server server = new Server();
// 注册服务
server.register(HelloService.class, HelloServiceImple.class);
// 启动并绑定端口
server.start(8020);
}
}新建用于调用服务的Maven应用，并引入刚编写的接口应用依赖。
groupId：org.book
artifactId：rpc-client
version：0.0.1-SNAPSHOT
packaging：jar① 在pom.xml文件中引入依赖。
<dependency>
<groupId>org.book</groupId>
<artifactId>rpc-interface</artifactId>
<version>0.0.1-SNAPSHOT</version>
</dependency>② 编写远程调用类。
public class Client<T> {
@SuppressWarnings("unchecked")
public static <T> T get(final Class<?> serviceInterface, final InetSocketAddress addr) {
T instance = (T) Proxy.newProxyInstance(serviceInterface. getClassLoader(), new Class<?>[]{serviceInterface},
new InvocationHandler() {
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
Socket socket = null;
ObjectOutputStream output = null;
ObjectInputStream input = null;
try {
// 连接服务端
socket = new Socket();
socket.connect(addr);
// 将调用的接口类、方法名、参数列表等序列后发送给服务提供者
output = new ObjectOutputStream(socket.getOutputStream());
output.writeUTF(serviceInterface.getName());
output.writeUTF(method.getName());
output.writeObject(method.getParameterTypes());
output.writeObject(args);
// 同步阻塞等待服务器返回应答，获取应答后返回
input = new ObjectInputStream(socket.getInputStream());
return input.readObject();
} finally {
if (socket != null) socket.close();
if (output != null) output.close();
if (input != null) input.close();
}
}
});
return instance;
}
}使用JDK动态代理方式，根据提供的服务接口类将接口序列化成码流，向目标服务端发起Socket远程调用请求，获得服务端反馈的结果并反序列化成对象后返回。
③ 调用测试。
public class App {
public static void main(String[] args) throws IOException {
HelloService service = Client.get(HelloService.class, new InetSocketAddress ("localhost", 8020));
System.out.println(service.hello("RPC"));
}
}运行结果如下所示：
// 客户端
hello : RPC
// 服务端
服务已启动
收到消息：RPC本章示例代码详见异步社区网站本书页面。
服务之间的调用已基本实现，但想将它投入正式开发使用还有很多细节需要完善。
当请求过大后会发现，BIO（同步阻塞式）的通信方式会消耗过多的资源导致服务器变慢甚至崩溃。
在发起网络请求前，将对象转换成二进制串便于网络传输；收到消息请求后，将二进制串反转换成对象便于后续处理。序列化及反序列化直接影响到整个RPC框架的效率及稳定性。
发起服务调用时，都需要指定服务提供方的访问地址（ip + 端口），如果当前服务提供方有多个或一个服务部署在多个机器上，调用时每次手动指定访问地址非常麻烦，这时就需要一个公共的注册中心去管理这些服务。
实施微服务的目的是为了让系统在进行横向扩展时能够拥有更多的计算资源，如果发现某一提供服务的机器负载较大，这就需要将新的需求转发到其他空闲的机器上。
服务提供方有可能崩溃无法继续提供服务，在客户端进行调用时就需要将这些无法使用的服务排除掉。
当服务端有异常发生导致无法返回正确的结果时，客户端并不知道该如何处理，只能等待并最终以超时结束此次远程调用请求。
以上所有的问题在后续将要介绍的Dubbo与Spring Cloud分布式框架中都得到了很好的解决，甚至基于Spring Boot构建的应用能让整个开发过程变得轻松愉快。
阿里巴巴在2011年开源了Dubbo框架，虽然在2013年停止更新，但在2017年9月又重启维护并发布了新版本。目前已有很多的公司将自己的业务建立在Dubbo之上，同时阿里云也推出了企业级分布式应用服务EDAS，为Dubbo提供应用托管。
Dubbo采用Zookeeper作为注册中心，RPC作为服务调用方式，致力于提供高性能和透明化的RPC远程服务调用方案。它与Spring无缝集成，基于服务提供方（服务端）与服务调用方（客户端）角色构建简单模型，其优点是使用方便、学习成本低。
① 服务提供方发布服务到服务注册中心。
② 服务消费方从服务注册中心订阅服务。
③ 注册中心通知消息调用方服务已注册。
④ 服务消费方调用已经注册的可用服务。
⑤ 监控计数。
Spring Cloud基于Spring Boot实现，使用HTTP的RESTful风格API作为调用方式。它所包含的多个子项目共同构建了微服务架构体系。
Spring Cloud 的服务注册中心提供服务注册、服务发现、负载均衡等功能。
当某个服务发生故障之后，则触发熔断机制（Hystrix）向服务调用方返回结果标识错误，而不是一直等待服务提供方返回结果，这样就不会使得线程因调用故障服务而被长时间占用不释放，避免了故障在分布式系统中的蔓延。
代理各模块提供的服务，统一暴露给第三方应用。提供动态路由、监控、弹性、全等的边缘服务。
分布式架构下多微服务会产生非常多的配置文件，分布式配置中心（Config Server）将所有配置文件交由GIT或SVN进行统一管理，避免出错。
在使用Spring开发时，通常需要完成Spring框架及其他第三方工具配置文件的编写，非常麻烦。Spring Boot通过牺牲项目的自由度来减少配置的复杂度，约定一套规则，把这些框架都自动配置集成好，从而达到“开箱即用”。
2.1 拆分逻辑
2.2 单模块
2.3 基础模块
2.4 复杂模块
将完整地使用本地调用方式的垂直应用拆分成多个微小的服务，每个服务模块负责提供各自独立的服务接口，并通过网络调用的方式将各个服务模块组织起来形成完整的微服务系统。
这里介绍微服务架构中拆分模块的基本逻辑，更为完善的模块拆分可以基于领域驱动设计（Domain-Driven Design，DDD）进行。
模块拆分是分布式微服务实施时的困难之一，它将直接影响到系统的复杂度、团队协作、代码维护难度、硬件资源分配等方面。模块拆分得越细，则能够更灵活地分配硬件资源与更方便地进行团队协作，但这样也会增加系统复杂度与代码维护难度，在团队人数较少的情况下无疑增加了负担。拆分模块时需要以具体的业务需求与系统请求压力分布为出发点进行权衡取舍。
业务的复杂性决定了被拆分的模块之间必然存在一定的依赖，模块被拆分得越细就意味着会产生更多的依赖关系，在拆分解耦的同时必然增加了整个系统的复杂度。
随着业务的丰富不可避免地使系统越来越复杂，我们没有办法拒绝复杂但应通过规范、约定、框架等手段尽量做到结构及代码的清晰与整洁。
当垂直应用变得庞大且复杂需要更多的工程师维护时，一般会使用Maven的多模块依赖特性将单一的应用拆分成多个模块，每个模块分给不同的工程师维护，最终团队成员提交模块，根据依赖关系打包成一个应用发布。
微服务天生由多模块组成，各个模块交由具体的专人负责，团队之间通过模块所暴露的服务进行协作。拆分模块的同时也确定了团队协作的方式。
微服务能够解决在垂直应用中错综复杂的业务逻辑耦合在一起的维护困难问题，但也并不是将模块拆分得越细越好，过多的模块反而会增加工作量与代码维护难度。
每个模块都处理着属于自己的业务逻辑，它们提供服务并维护着与其他模块的依赖关系，如果服务提供方的返回结果发生了变动，则各个调用方均要修改自己的代码。
在实际开发中不可避免地要跨模块调试，调试过程中所涉及的模块数量越多，则整个过程就越麻烦。
系统中存在请求压力不均衡的情况，模块拆分得越细，则能更有针对性地为高压力模块分配更多的计算资源，避免浪费。
为了设计出低耦合、高内聚的系统，需要确保每个模块都具有一定的独立性，每个模块只完成它所负责的业务功能，并且模块之间做到最少联系及接口简单。模块之间的边界则是思考的重点。
单个模块内聚了相关性较强的功能，并且拥有独立的数据库（ORM）、单元测试、运行内存、业务逻辑处理等。可以将单个模块看成是一个完整的垂直应用，只是在输入（接受请求）、输出（结果输出）时有差别。
大部分请求都是同步的，即消费方发起请求后等待提供方完成计算并返回结果，但如果等待的过程过于漫长，则需要借助消息队列与回调将请求的过程变为异步，消费方向服务提供方的消息队列中发送请求消息，服务方计算完成后调用消费方的方法通知结果。
异步请求适合处理批量处理类的功能，例如群发邮件，一次性发送1000封邮件需要一定的发送时间，采用异步处理，则消费方只需向发送邮件的服务队列中增加收件列表，任务完成后调用消费方的接口告知发送结果即可。
一个复杂的业务功能需要依赖多个模块所提供的功能实现，在进行模块拆分时需要提前对业务所涉及的模块进行梳理，最终如图所示， 各个模块由上至下依次层级依赖。
各个模块提供的服务具有一定的原子性，保持独立不重叠。将不需要依赖其他模块或依赖较少的模块抽象为基础模块，为更为复杂的业务逻辑做准备，提高复用性与扩展性。
为实现复杂业务将基础模块进行聚合重组时，每个模块对自身数据库操作事务的管理比较简单，但基于网络跨模块的二阶事务管理则会将整个过程变得无比复杂，并且耗费更多的资源，所以在进行模块拆分时且尽量规避二阶事务的产生。在无法避免分布式事务的情况下，可以采用 TCC（Trying Confirming Canceling）补偿性事务解决方案实现对二阶事务的管理。
垂直应用在处理购物车或登录状态管理等功能时一般会基于Session实现，但在分布式架构下Session的共享与传递会增加整个系统的耦合度并且提高复杂性。模块在处理自身业务逻辑及服务调用时，尽量以无状态协议的角度进行设计，请求完立刻释放资源。维护状态的工作可由服务提供方增加状态检查的服务，但面对高查询、低修改的场景时可以基于约定交由公共缓存系统（Redis）维护。
复杂的订单模块为了产生一张订单，需要用户模块提供的买卖双方信息，产品模块提供的货物信息，财务模块提供的账户余额、消息模块提供的短信通知等基础服务。
