SOA 架构
SOA 全称是：Service Oriented Architecture，“面向服务的架构”。
它是一种设计理念，其中包含多个服务，服务之间通过相互依赖最终提供一系列完整的功能。
各个服务通常以独立的形式部署运行，服务之间通过网络进行调用。
跟 SOA 相提并论的还有一个 ESB(企业服务总线)，简单来说 ESB 就是一根管道，用来连接各个服务节点。
ESB 的存在是为了集成基于不同协议的不同服务，ESB 做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通。
SOA 所要解决的核心问题是：
-
系统间的集成：站在系统的角度来看，首先要解决各个系统间的通信问题。目的是将原先系统间散乱、无规划的网状结构，梳理成规整、可治理的星形结构，这步的实现往往需要引入一些概念和规范。比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是【有序】。
-
系统的服务化：站在功能的角度，需要把业务逻辑抽象成可复用、可组装的服务，从而通过服务的编排实现业务的快速再生。目的是要把原先固有的业务功能抽象设计为通用的业务服务、实现业务逻辑的快速复用；这步要解决的核心问题是【复用】。
-
业务的服务化：站在企业的角度，要把企业职能抽象成可复用、可组装的服务，就要把原先职能化的企业架构转变为服务化的企业架构，以便进一步提升企业的对外服务的能力。“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。而本步骤，则是以业务驱动把一个业务单元封装成一项服务。要解决的核心问题是 【高效】。
微服务（Microservices）架构
微服务架构和 SOA 架构非常类似，微服务是 SOA 的升华，只不过微服务架构强调的是“业务需要彻底的组件化及服务化”，原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用。这些小应用间通过服务化完成交互和集成。 组件表示的就是一个可以独立更换和升级的单元，就像 PC 中的 CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。
微服务不再强调传统 SOA 架构里面比较重的 ESB 企业服务总线，同时以 SOA 的思想进入到单个业务系统内部实现真正的组件化。
Docker 容器技术的出现，为微服务提供了非常便利的条件，比如更小的部署单元，每个服务可以通过类似 Spring Boot 或者 Node 等技术独立运行。
微服务的特征：
-
通过服务实现组件化
-
按业务能力来划分服务和开发团队
-
去中心化
-
基础设施自动化(DevOps、自动化部署)
服务网格（Service Mesh）架构
非侵入式的 Service Mesh 技术慢慢走向了成熟。Service Mesh (服务网格)，作为服务间通信的基础设施层在系统中存在。
什么叫 Service Mesh，我们可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务间的网络调用、熔断、限流和监控。
我们都知道在编写应用程序时程序猿一般都无须关心 TCP/IP 这一层（比如提供 HTTP 协议的 Restful 应用）。同样如果使用服务网格我们也就不需要关心服务间的那些原来是由应用程序或者其他框架实现的事情(熔断、限流、监控等)，现在只要交给 Service Mesh 就可以了。
微服务更注重服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信以及和 DevOps 更好的结合等。
服务网格的特征：
-
应用程序间通讯的中间层
-
轻量级网络代理
-
应用程序无感知
-
解耦应用程序的重试/超时、监控、追踪和服务发现
分布式架构下的高可用设计
避免单点故障：
-
负载均衡技术(failover/选址/硬件负载/ 软件负载/去中心化的软件负载(gossip(redis- cluster)))
-
热备(Linux HA)
-
多机房(同城灾备、异地灾备)
应用的高可用性：
-
故障监控(系统监控(CPU、内存)/链路监控/日志监控) 自动预警
-
应用的容错设计、(服务降级、限流)自我保护能力
-
数据量(数据分片、读写分离)
分布式架构下的可伸缩设计：
-
垂直伸缩
-
提升硬件能力
-
水平伸缩
-
增加服务器