Java程序员进阶必读，最全微服务架构技术点详解来啦

微服务作为这个互联网时代最火的技术之一，想必大家即使没有学习过也有所了解，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。

每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API).每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。

另外，应尽量避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

历史演变：

　　以前我们都是一个war包，包含了很多很多的代码，反正我开始工作的时候做的就是这样的项目，一个金融系统，代码具体多少行记不清楚了，内部功能超多，但是实际能用到的不多，代码冗余超大，每次部署大概要10分钟以上。

　　这个war包包含了我们的所有，jsp、js、css、java代码。代码很臃肿，每次改BUG很容易“碰瓷”。还有很多很多的方面，这里就不一一列举了。画个图~！

  慢慢的我们的用户越来越多了，一台服务器扛不住了，我们于是乎有横向扩展，有了nginx，貌似可以解决我们的一些问题了。

　　

　但是...假如我们现在要搭建一个宝淘商城，内部包含内部订单模块，积分模块，支付模块，用户模块等等，都挤在一个war包，假如订单模块需要电脑的磁盘IO，支付模块需要我们的CPU计算，这样我们的服务器一定是既有一个好的CPU又有一个好的磁盘，也会造成我们的服务器成本很高。

　　貌似这样可以解决问题，但是还不是最优质的，这时来了一个大佬，马丁福勒，就是这个人。

他第一次提出了微服务的思想。我们来简单拆分一下。

 　　届时用户量大增，我们觉得我们的订单服务有压力了，我们只需要增加我们的订单服务的服务器就可以了。

 我们来明确几个定义，什么是微服务？什么又是微服务架构？

　　 微服务：微服务核心就是把传统的单机应用，根据业务将单机应用拆分为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能，一个服务只做一件事,类似进程， 每个服务都能够单独部署，甚至可以拥有自己的数据库。这样的一个一个的小服务就是 微服务。这个是摘自马丁福勒的文章。比如我们的订单服务，可以成为一个微服务，我们的积分服务，也可以成为一个微服务。

　　 微服务架构：微服务架构是指把 一个一个的微服务组合管理起来，对外提供一套完整的服务。 

对比优缺点：

　　我们现在有了微服务架构，难道我们所有的项目都可以调整为微服务架构吗？我们来看看传统架构和微服务架构的优缺点。

　　传统架构优点：

　　①.就一个war包，运维超级幸福。

　　②.架构简单明了，没有那些分布式事务，分布式锁等等问题。

　　传统架构缺点：

　　①.代码臃肿，每个程序员需要了解所有模块的代码。

　　②.代码质量参差不齐，每次改BUG容易碰瓷。

　　③.不便于做扩展，架构限制性强，扩展成本高。

　　④.部署难，代码行过多，部署半小时很正常。

　　⑤.如果一个非核心模块出现问题，会造成整体系统不可用，比如积分模块内存溢出，倒置整个系统宕机。

　　看起来传统架构缺点还是不少的，但是也不是每个项目都适合微服务架构的，比如一个小OA系统，本来功能就不多，你没有必要去拆分服务了，对吧~！我们再来看看微服务给我们带来了什么优缺点吧。

　　微服务的优点：

　　①.程序员不需要了解整体业务，只需专心研究自己关注的业务即可。

　　②.改BUG时不用提心吊胆，顶多影响自己的服务不可用，不会导致整体不可用。

　　③.便于后期的扩展，也可以随时应对需求的变化。

　　微服务的缺点：

　　①.部署困难，对于运维人员有一些压力（k8s+docker+jenkis ）

　　②.服务之间的通讯增加了通讯成本。

　　③.带来了分布式事务，分布式锁，分布式JOB等等问题等待我们来解决。

　　 微服务的适用场景：合适，大型复杂的项目(来自单体架构200W行代码的恐惧) ，适合快速迭代的项目(来自一天一版的恐惧) ，适合并发高的项目(考虑弹性伸缩扩容的恐惧) ，但我们的微服务不合适那些业务稳定，就是修修bug ，改改数据的系统，迭代周期长，发版频率一二个月一次的稳定系统。

微服务架构是一个架构风格, 提倡

　　①.将一个单一应用程序开发为一组小型服务。

　　②.每个服务运行在自己的进程中。

　　③.服务之间通过轻量级的通信机制(http rest api)

　　④.每个服务都能够独立的部署

　　⑤.每个服务甚至可以拥有自己的数据库 

虽然微服务不会作为面试的主要内容，但是微服务在这个互联网时代作为最火热的技术之一，在当下互联网企业不懂微服务是不行的，今天我就免费分享一份微服务架构笔记给大家，这份笔记包含了Dubbox+Spring Boot+Docker+SpringCloud的技术点详解，也有人凭借这份微服务架构笔记进了大厂，话不多说，上干货！

涵盖44个架构设计模式，系统解决服务拆分、事务管理、查询和跨服务通信等难题

易宝支付CTO陈斌、PolarisTech 联合创始人蔡书、才云科技CEO张鑫等多位专家鼎力推荐

本书的目标是让架构师和程序员学会使用微服务架构成功开发应用程序。

书中不仅讨论了微服务架构的好处，还描述了它们的弊端。读者将掌握如何在使用单体架构和使用微服务架构之间做出正确的权衡。

谁应该阅读本书

本书的重点是架构和开发，适合负责开发和交付软件的任何人(例如开发人员、架构师、CTO或工程副总裁)阅读。

本书侧重于解释微服务架构的设计模式和其他概念。无论读者使用何种技术栈，我的目标都是让你们可以轻松读懂这本书。你只需要熟悉企业应用程序架构和设计的基础知识即可。

特别是，需要了解三层架构、Web应用程序设计、关系型数据库、使用消息和基于REST的进程间通信，以及应用程序安全性的基础知识等概念。本书的代码示例使用Java和Spring框架。

为了充分利用它们，读者应该对Spring框架有所了解。

本书内容安排

本书由13章组成。

■第1章描述了所谓“单体地狱”的症状，当单体应用程序超出其架构时会出现这种问题，这可以通过采用微服务架构来规避。这一章还概述了微服务架构模式语言，这也是本书大部分内容的主题。

■第2章解释了为什么软件架构很重要，描述了可用于将应用程序分解为服务集合的模式，并解释了如何克服在此过程中遇到的各种障碍。

■第3章介绍了微服务架构中强大的进程间通信的几种模式，解释了为什么异步和基于消息的通信通常是最佳选择。

■第4章介绍如何使用Saga模式维护服务间的数据一致性。Saga 是通过传递异步消息的方式进行协调的一系列本地事务。

■第5章介绍如何使用领域驱动设计(DDD)的聚合和领域事件等模式为服务设计业务逻辑。

■第6章以第5章为基础，解释了如何使用事件溯源模式开发业务逻辑，事件溯源模式是一种以事件为中心的设计思路，用来构建业务逻辑和持久化领域对象。

■第7章介绍如何使用API组合模式或命令查询职责隔离(CQRS) 模式，这两个模式用来实现查询分散在多个服务中的数据。

■第8章介绍了处理来自各种外部客户端请求的外部API模式，例如移动应用程序、基于浏览器的JavaScript应用程序和第三方应用程序。

■第9章是关于微服务自动化测试技术的两章中的第-章，介绍了重要的测试概念，例如测试金字塔，描述了测试套件中每种测试类型的相对比例，还展示了如何编写构成测试金字塔基础的单元测试。

■第10章以第9章为基础，描述了如何在测试金字塔中编写其他类型的测试，包括集成测试、消费者契约测试和组件测试等。

■第11章介绍了开发生产就绪服务的各个方面，包括安全性、外部化配置模式和服务可观测性模式。服务可观测性模式包括日志聚合、应用指标和分布式追踪。

■第12章介绍了可用于部署服务的各种部署模式，包括虚拟机、容器和Serverless模式。还介绍了使用服务网格的好处，服务网格是在微服务架构中处理服务间通信的一个网络软件层。

■第13章介绍了如何通过采用绞杀者( Strangler)模式逐步将单体架构重构为微服务架构，绞杀者模式是指以服务形式实现新功能，从单体中提取模块将其转换为服务。

在学习这些章节的过程中，读者将了解微服务架构的不同方面。

关于本书中的代码

本书包含许多源代码示例，包括带有编号的代码清单和直接体现在正文中的代码。

在这两种情况下，源代码都以相同的等宽字体排版，以便与普通文本分开。有些情况下，代码被设定为粗体字，这用来表示相对之前的章节这些代码的内容已经发生了变化(例如当新功能添加到现有代码行时)。

在许多情况下，书中展示的源代码已经重新排版，出版商添加了换行符和缩进，以适应书中可用的页面空间。在极少数情况下，代码中会包括续行标记( > )。

此外，当正文中描述代码时，源代码中的注释通常从代码中删除了。一些代码段落会包含醒

目的粗体字提示和解释，这是用来强调重要概念的。

除第1章、第2章和第13章外，每章都包含来自配套示例应用程序的代码。读者可以在GitHub代码库( hts://github. com/microservices patterns/ftgo application)日中找到此应用程序的代码。

一共484页，如果你也在学习Java微服务，一定要看看这本书！

需要的小伙伴扫描下方二维码备注“微服务”即可免费获取👇👇👇