4：第二章：理解微服务架构，清楚微服务设计原则：1：微服务架构的，演进过程：单体架构→垂直应用架构→SOA架构→微服务架构；

本文链接：https://blog.csdn.net/csucsgoat/article/details/124963762

说明：

（1）本篇博客，介绍软件设计架构的演进历史；

微服务并不是一开始就出现、或者说就需要的；其实，在软件开发演进过程中，逐渐发展出来的；

1.单体结构；

说明：

（1）单体架构非常简单，这个简单不是说单体架构中的业务开发简单，而是说单体架构的设计简单；

（2）单体架构，将整个业务的功能实现，写在一个工程中；比如，对于一个电商系统来说，用一个Java应用就能hold住；这个电商系统包括鉴权、监控、账户、商品等模块；

（3）优点：如果工程体量不是很大、业务不是很多，那么单体架构完全是可以的；很多中小型企业在一开始的时候，大都选择单体架构；

（4）缺点：开发时，不同人员提交代码时候，容易产生代码冲突；不同模块见耦合严重；

随着业务的不断发展，工程的体量也逐渐变大，单体架构的瓶颈越来越明显；由此，在单体架构的基础上，出现了垂直应用架构；垂直应用架构是对单体架构的升级和改进；

2.垂直应用架构；

说明：

（1）垂直的意思是，单一的业务场景；比如，电商、外卖、音乐这些，都是独立业务领域，都是单独的业务场景；

● 当我们做这些场景的实现时，就可以说【我们垂直于电商开发】、【我们垂直于音乐开发】；

（2）而在某个具体的业务场景中，又可以细分小的垂直领域；

● 以电商这种场景为例，其中的鉴权、账户、商品、订单等，都是垂直的功能服务；

（3）以电商这种场景为例，我们把鉴权、账户、商品、订单等，单独拿出来去开发部署，就形成了所谓的垂直应用架构；

● 鉴权、账户、商品、订单等，都有独立的数据库；

● 鉴权、账户、商品、订单等，都有各自不同的、独立的域名；（因为鉴权、账户、商品、订单等都是各自单独去部署的）

（4）优点：条理清晰；容易理解；

（5）缺点：这种架构搭建复杂，耗费的资源比较多；以电商这种场景为例，鉴权、账户、商品、订单等应用之间的关系，错综复杂；较难维护；

垂直应用架构，经过验证，这种架构并不是很好，其只经过短暂的发展周期就结束了；目前，市面上已经很少有这种架构设计了；后来，就出现了SOA架构设计；

3.SOA架构；

说明：

（1）SOA(Service-Oriented Architecture,面向服务的架构)，其是基于垂直应用架构的升级改进；在微服务出现的前几年，这种架构设计应用的比较广泛；

（2）SOA，是将耦合的系统，划分为面向业务的粗粒度、粗偶合、无状态服务；；；某个服务发布出来后，会被其他服务调用；；；一组互相依赖的服务，就构成了SOA架构的系统；

（3）SOA并不是某种具体的技术实现，其只是一种系统架构设计思想；；；随着软件系统越来越复杂，需要解决的问题也越来越复杂，以前的垂直应用架构难以应付，由此就出现了SOA架构；

（4）SOA架构中，业务的划分，不再是小块的业务逻辑，而是大块的业务逻辑，比如，整个的电商系统、整个的CMS系统；

● 这些大块的业务逻辑，仍然依赖于最底层的小模块的服务；

● 【上面的、大块的业务逻辑】调用【下面的、底层的小模块的服务】时，有统一的入口ESB（Enterprise Service Bus企业服务总线）；

● ESB就是一个管道，用于连接各个服务节点，以集成不同系统不同服务；；；ESB做了消息的转化解释和路由工作，以让不同的服务互联互通；

（5）优点：提供了【下面的、底层的小模块的服务】的统一入口；简化了客户端的调用；

（6）缺点：SOA设计，实现难度较高，开发周期较长；如果业务逻辑划分太大，会存在一定的耦合；

…………………………………………………………………………………………

PS：SOA中体现的，可复用、解耦、灵活的组装编排思想，是没有过时的；其在目前的工作、技术、产品、实现中，都大量的体现和应用；在中台（中台的核心思想就是，共性的业务能力下沉；然后，上层的前台业务可以基于这些共性的业务能力，去灵活的复用和组装，快速的实现上层的应用）、微服务（共性能力下沉后，共性的能力进步一拆分，拆分为一个个小的组件，也就是拆分成一个一个的微服务）中，也都很明显的体现了这种思想；

近几年，以前的SOA等架构，都存在或多或少的缺陷；由此，提供了微服务架构的设计思想；

4.微服务架构；

说明：

（1）微服务的入口，不再ESB，而是服务网关；；；服务网关，可以接受任何类型的客户端的访问请求；

● 网关可以实现对请求的过滤和转发；

（2）通过网关过滤的请求，将会被转到对应的微服务上；；；比如，某个请求想要查看账户信息，那么这个请求将会由网关路由到账户微服务；

（3）微服务是从一个独立的系统中，拆分出来的独立服务；每个微服务，运行在自己的进程中；每个微服务是独立部署的；；；一个应用系统，经过功能拆分出若干个微服务，每个微服务实现一部分功能；那么这些微服务，共同构成了完整的应用系统；

（4）通常，不同微服务之间，通过HTTP（具体就是Rest）方式来通信，而且不同的微服务共用一个数据库、缓存、消息队列等资源；

（5）微服务，需要依赖一些特定的组件或者说中间件；

● 服务注册、服务发现：能够实现对微服务的管理和监控；微服务之间也能够知道互相的存在；

● 服务配置：将各个微服务需要动态配置的内容，提取出来，进行统一的管理和实现动态配置；

● 服务通信：实现微服务之间的胡通；

● 消息驱动：通过消息队列，微服务之间互相通信；；；其通常，应用于异步通信，或者说实时性要求不高的通信；

● 熔断限流：微服务请求发生问题时候，能够妥善的处理；

● 分布式日志追踪：比如某个请求可能会跨越多个微服务，那么想要去查看某个请求的完整的日志链路，就可以使用分布式日志追踪工具；

● 分布式事务：对于单体应用来说，发生的都是本地事务，即某个请求涉及的所有对数据库的更改，都发生在一个事务中；；；但是，对于微服务来说，每个微服务内部都是本地事务，多个微服务之间的协同合作，就变成了分布式事务；我们需要对这样的请求操作加以协调；也就是分布式事务；