一、单体架构

1.1 介绍

• 单体架构在历史进程里，出现时间最早，应用范围最广、使用人数最多、统治历史最长。
• 单体 这个词是从微服务开始流行后，“事后追认”的一种架构。
• 很多微服务的介绍中，将其称之为 **巨石系统 （Monolithic Application） **

1.2 优点

1. 易于开发调试、测试、部署、开发。
2. 运行效率比分布式系统药膏
3. 架构简单，开发快成本低

1.3 缺点

1. 项目模块耦合严重，维护和沟通成本会更高，无法对某类高峰业务单独进行拓展，只能针对整体进行拓展。
2. 核心业务和边缘业务互相影响，导致系统可靠性不足。
3. 到了后期系统工程愈发庞大后，新增功能会非常复杂，同时不利于开发、运维。工程混乱

1.4 总结

单体并不就代表落后的系统架构风格，单体作为一个小型系统，不需要进程间通信易于部署、易于测试、开发、部署、调试。且效率比分布式系统更高。适合需求少、并发小，要求快速开发交付的项目初期发展阶段。未来会长期存在。

二、垂直架构

2.1 介绍

1. 垂直架构一般是因为单体架构太过于庞大而进行的拆分，拆分后各个系统应满足独立运行互相不影响
2. 也有可能时某个平台招标由不同厂商负责不同子系统的开发
3. 垂直架构可以看成是多个单体架构的组合

2.2 优点：

1. 对比单个单体架构系统，它拆分了系统的流量，可以针对高峰共功能进行拓展
2. 优化了单体架构过于庞大时出现的难以维护的问题。

2.3 缺点：

1. 在各个系统间单体架构存在的问题仍然存在并且有新的问题产生
2. 会有功能的重叠，重复造轮子
3. 拆分后存在隔离与治理能力上的欠缺，并且会给技术异构带来麻烦。
4. 拆分后可能带来数据冗余，但是又需要进行同步，要么使用数据库层面的同步，要么使用系统间的接口进行同步处理。
5. 系统之间的交互，由于缺少隔离与治理能力，一般都是硬编码的点对点交互。

三、分布式架构

• 分布式架构 简单来说就是一组计算机组成一个系统的整体，一致对外提供服务
• 这组计算机内的不同系统，都可以互相通信
• 客户端到服务端的一次请求响应，可能会历经多台计算机。

四、分布式架构-SOA

IBM对SOA的介绍：https://www.ibm.com/cn-zh/topics/soa

4.1 SOA架构的历史

1. SOA最早时由Gartner公司，1994年提出但当时没有发展条件。
2. 2006年 IBM、Oracle、SAP等公司，成立了OSOA联盟，来指定SOA的相关行业标准
3. 2007年 结构化咨询标准促进组织 OASIS 的倡议和支持下，OSOA联合OASIS成立了 Open CSA组织，也就是SOA的官方管理机构。
4. 到SOA时代，许多概念都能在微服务中找到对应的身影了。例如服务之间的松耦合、注册、发现、治理、隔离、编排等等。

4.2 介绍

1. SOA有自己的技术标准组织，OPEN CSA、有清晰的设计指导原则比如服务的封装性、自治、松耦合、可重用、可组合、无状态，等等.
2. SOA 架构明确了采用 SOAP 作为远程调用的协议，依靠 SOAP(简单对象访问协议) 协议族（WSDL、UDDI 和一大票 WS-* 协议）来完成服务的发布、发现和治理；
3. Web Service 广义来说是服务网络化基于WEB传输的能力。但是一般指 基于SOAP协议实现的远程服务调用模型。
4. SOA 架构会利用一个被称为是企业服务总线（Enterprise Service Bus，ESB）的消息管道，来实现各个子系统之间的通讯交互，这就让各个服务间在 ESB 的调度下，不需要相互依赖就可以实现相互通讯，既带来了服务松耦合的好处，也为以后可以进一步实现业务流程编排（Business Process Management，BPM）提供了基础；
5. SOA 架构使用了服务数据对象（Service Data Object，SDO）来访问和表示数据，使用服务组件架构（Service Component Architecture，SCA）来定义服务封装的形式和服务运行的容器；

4.3 优点

1. 对公共服务进行拆分，避免了重复造轮子问题。抽离出的服务使用ESb企业总线来进行规范的同意信息交互，避比原来点对点的交互模式耦合度更低。
2. 对比垂直架构，SOA对业务的拆分更清晰、职责更单一拓展性更强。
3. 不强行打通数据库层面壁垒，让数据回到隔离状态，信息孤岛由接口解决。
4. 系统架构有详实的标准。

4.4 缺点

1. 通过ESB中转带来的性能损耗，所有交互通过ESB进行，ESB宕机后所有系统都会受到牵连。
2. 公共服务抽取后，业务系统和服务之间高度耦合。
3. 复杂度太高，不利于一般的开发

4.5 总结

SOA 架构过于严谨精密的流程与理论，导致了软件开发的全过程，都需要有懂得复杂概念的专业人员才能够驾驭。从 SOA 诞生的那一天起，就已经注定了它只能是少数系统的阳春白雪式的精致奢侈品：它可以实现多个异构大型系统之间的复杂集成交互，却很难作为一种具有广泛普适性的软件架构风格来推广。Web Service被边缘化的本质，也是因为过于严格的规范定义，带来了过度的复杂性。

五、微服务架构

一句话介绍微服务
微服务是一种通过多个小型服务的组合，来构建单个应用的架构风格，这些服务会围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言、不同的数据存储技术、运行在不同的进程之中。服务会采取轻量级的通讯机制和自动化的部署机制，来实现通讯与运维。

康威定律：设计系统的架构受制于产生这些设计的组织的沟通结构

5.1 历史

1. Peter Rodgers 博士在 2005 年的云计算博览会（Web Services Edge 2005）上，就已经提出和使用，指的是一种专注于单一职责的、与语言无关的、细粒度的 Web 服务（Granular Web Services）。
2. 早期的微服务被认为是SOA的一种轻量化补救方案
3. 2021年 Thoughtworks 首席咨询师 James Lewis 的演讲 《Microservices - Java, the Unix Way》 号召大家重拾Unix的设计哲学
4. 2014年 微服务崛起，Martin Fowler 和 James Lewis 合写的文章“Microservices: a definition of this new architectural term”让人们真正了解到微服务。

5.2 微服务的核心业务与技术特征

1. 围绕业务能力构建 Organized around Business Capabilities
2. 分散治理（Decentralized Governance） 表达的是“谁家孩子谁来管”。微服务不反对也不提倡技术上的统一，只要能维护号自己的服务。
3. 通过服务来实现独立自治的组件（Componentization via Services）
4. 产品化思维（Products not Projects）避免把软件研发看作是要去完成某种功能，而要把它当做是一种持续改进、提升的过程
5. 数据去中心化（Decentralized Data Management）数据应该按领域来分散管理、更新、维护和存储。虽然更容易导致一致性的问题，但是为了独立性有些代价是必须要付出的。
6. 轻量级通讯机制（Smart Endpoints and Dumb Pipes）反对ESB、BPM和SOAP等复杂的通信机制。微服务体长类似于Unix一样简单直接地通信方式，RESTful风格的通信在微服务中就很合适。
7. 容错性设计（Design for Failure） 不再追求服务永远稳定不出错，而是接受服务总会出错的现实。可靠的系统完全可以由会出错的服务来组成。容错性设计要求：
   1. 有自动的机制能快速检测故障
   2. 持续出错时，能对出错的服务进行隔离，服务恢复时自动联通(所以熔断器在微服务环境中时必须的) 没有这一项容易导致系统雪崩
8. 演进式设计（Evolutionary Design） 容错性设计承认服务会出错，而演进式设计则是承认服务会被报废淘汰。一个良好的设计服务应该是能够报废的，否则一个服务不可替代，则说明这是系统设计的脆弱。微服务带来的独立、自治就是再反对这种脆弱。
9. 第九，基础设施自动化（Infrastructure Automation） 基础设施的自动化，例如CI/CD的发展，大大降低了构建、发布、运维工作的复杂性。

自由的架构风格

1. 微服务没有统一的约束和规定，提倡以"实践标准" 代替 " 规范标准"
2. 服务的注册发现、跟踪治理、负载均衡、故障隔离、认证授权、伸缩拓展、传输通讯、事务处理等问题。在微服务中不再会有统一的解决方案。
3. 例如在 Java 范围内的微服务通讯问题，可以选区的方案就很多：RMI（Sun/Oracle）、Thrift（Facebook）、Dubbo（阿里巴巴）、gRPC（Google）、Motan2（新浪）、Finagle（Twitter）、brpc（百度）、Arvo（Hadoop）、JSON-RPC、REST，等等。
4. 服务发现的解决方案：Eureka（Netflix）、Consul（HashiCorp）、Nacos（阿里巴巴）、ZooKeeper（Apache）、etcd（CoreOS）、CoreDNS（CNCF），等等。

5.3 总结

优点：

1. 已于开发和维护，服务拆分的足够细
2. 启动速度快、不限制技术栈、局部修改容易

缺点：

1. 分布式固有的复杂性 容错、延迟、事务 等都是必须考虑的。
2. 接口调整成本高
3. 服务公用的功能需要内聚，可能会重复。
4. 服务更多的话，运维就会更复杂

总结

1. 微服务中，不需要背上SOA的包袱，需要解决什么问题就引入什么工具，团队熟悉什么技术就是用什么框架
2. 类似Spring Cloud的胶水式全家桶，通过一致的接口、声明、配置 进一步屏蔽了源自具体工具、框架的复杂性。也降低了不同工具、框架的切换成本。对于开发者来说，微服务架构是友善的。

六、目前分布式架构的通信方式

因为传统的单体架构，服务都部署在一个主机上所以不涉及远程服务调用，但是对分布式系统来说，服务间的调用就是实现分布式的关键因素

6.1 直接使用HTTP协议进行服务间通信

HttpURLConnection
java 原生 HttpURLConnection是基于http协议的，支持get，post，put，delete等各种请求方式，最常用的就是get和post
Apache Common HttpClient
HttpClient 是Apache Common 下的子项目，可以用来提供高效的、最新的、功能丰富的支持HTTP 协议的客户端编程工具包，并且它支持 HTTP 协议最新的版本。实现了所有 HTTP 的方法（GET,POST,PUT,HEAD 等）支持 HTTPS 协议支持代理服务器等
OKhttp3
OKHttp是一个当前主流的网络请求的开源框架, 用于替代HttpUrlConnection和Apache HttpClient支持http2.0，对一台机器的请求共享一个socket。采用连接池技术，可以有效的减少Http连接数量。无缝集成GZIP压缩技术。支持Response Cache，避免重复请求
域名多IP支持
RestTemplate
Spring RestTemplate 是 Spring 提供的用于访问 Rest 服务的客户端，RestTemplate 提供了多种便捷访问远程Http服务的方法，能够大大提高客户端的编写效率，所以很多客户端比如 Android或者第三方服务商都是使用 RestTemplate 请求 restful 服务。

1. 面向 URL 组件，必须依赖于主机 + 端口 + URI
2. RestTemplate 不依赖于服务接口，仅关注 REST 响应内容
3. Spring Cloud Feign 是基于RestTemplate实现

6.2 使用RPC框架进行服务间通信

在RPC最初出现时，大家都奔着让计算机调用远程服务跟调用本地服务一样。“透明的RPC调用一成为主流”。但是后来发现，这样让人们误以为通信是没有成本的，后来还出现了 “通过网络进行分布式运算的八宗罪”。这八宗罪就是程序员在网络编程中经常忽略的问题。所以后面RPC就不能等同于IPC去实现，不能奔着透明化去走。

• RPC全称为remote procedure call，即远程过程调用，借助RPC可以做到像本地调用一样调用远程服务，是一种进程间的通信方式 。
• RPC协议可以基于HTTP 例如Web Service 、也可以基于TCP协议进行传输
• RPC框架解决的问题主要是 1 传递数据 2表达数据 3标识方法

常见的RPC框架有一下几种。
Java RMI
Java RMI（Romote Method Invocation）是一种基于Java的远程方法调用技术，是Java特有的一种RPC实现。

Hessian
Hessian是一个轻量级的remoting onhttp工具，使用简单的方法提供了RMI的功能. 相比
WebService，Hessian更简单、快捷。采用的是二进制RPC协议，因为采用的是二进制协议，所以它很适合于发送二进制数据。

Dubbo
Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。Dubbo是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

gRPC
gRPC是由Google公司开源的一款高性能的远程过程调用(RPC)框架，可以在任何环境下运行。该框架提供了负载均衡，跟踪，智能监控，身份验证等功能，可以实现系统间的高效连接。