1.1系统架构的演变
随着互联网的发展，网站应用的规模不断扩大，常规的应用架构已无法应对，分布式服务架构以及微服务架构势在必行，亟需一个治理系统确保架构有条不紊的演进。
1.1.1单体应用架构
Web应用程序发展的早期，大部分web工程(包含前端页面,web层代码,service层代码,dao层代码)是将所有的功能模块,打包到一起并放在一个web容器中运行。
比如搭建一个电商系统：客户下订单，商品展示，用户管理。这种将所有功能都部署在一个web容器中运行的系统就叫做单体架构。
优点：
-
系统的简易性：系统语言风格、业务结构，接口格式均具有一致性，服务都是耦合在一起的，不存在各个业务通信问题。
-
易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，简化了测试过程，无需额外测试服务间的依赖，测试均可在部署完成后开始。
-
易于部署与升级：相对于微服务架构中的每个服务独立部署，单体系统只需将单个目录下的服务程序统一部署和升级。
-
较低的维护成本：只需维护单个系统即可。运维主要包括配置、部署、监控与告警和日志收集四大方面。相对于单体系统，微服务架构中的每个服务都需要独立地配置、部署、监控和日志收集，成本呈指数级增长。
缺点：
-
复杂性高：由于是一个单体的系统，所以整个系统的模块是耦合在一起的，模块的边界比较模糊、依赖关系错综复杂。功能的调整，容易带来不可知的影响和潜在的bug风险。
-
服务性能问题：单体系统遇到性能瓶颈问题，只能横向扩展，增加服务实例，进行负载均衡分担压力。无法纵向扩展，做模块拆分。
-
扩缩容能力受限：单体应用只能作为一个整体进行扩展，影响范围大，无法根据业务模块的需要进行单个模块的伸缩。
-
无法做故障隔离：当所有的业务功能模块都聚集在一个程序集当中，如果其中的某一个小的功能模块出现问题（如某个请求堵塞），那么都有可能会造成整个系统的崩溃。
-
发布的影响范围较大：每次发布都是整个系统进行发布，发布会导致整个系统的重启，对于大型的综合系统挑战比较大，如果将各个模块拆分，哪个部分做了修改，只发布哪个部分所在的模块即可。
1.1.2垂直应用架构
当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率
优点：
-
项目架构简单，前期开发成本低，周期短，小型项目的首选。
-
通过垂直拆分，原来的单体项目不至于无限扩大
-
不同的项目可采用不同的技术。
缺点：
-
全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。
-
系统性能扩展只能通过扩展集群结点，成本高、有瓶颈。
1.1.3 分布式SOA架构
1.1.3.1 什么是SOA
SOA 全称为 Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进程中。
站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。通过上面的描述可以发现 SOA 有如下几个特点：分布式、可重用、扩展灵活、松耦合
1.1.3.2 SOA 架构
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求
优点：
-
抽取公共的功能为服务,提高开发效率
-
对不同的服务进行集群化部署解决系统压力
-
基于ESB/DUBBO减少系统耦合
缺点：
-
抽取服务的粒度较大
-
服务提供方与调用方接口耦合度较高
1.1.4 微服务架构
微服务：将原本大块的服务细化，变成粒度更小的服务。 使其耦合度更底，重用性更高。将服务拆分出去，也是为了降低单个服务的压力，避免服务经常因为负载过高而崩溃的问题。
优点：
-
通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成 本也将大幅度下降
-
微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。
缺点：
-
微服务过多，开发成本高
-
服务拆分如果不当，反而会适得其反
-
分布式系统开发的技术成本高（容错、分布式事务等）
1.1.5 SOA与微服务的关系
SOA（ Service Oriented Architecture ）“面向服务的架构”:他是一种设计方法，其中包含多个服 务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程 中。各个服务之间 通过网络调用。
微服务架构: 其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需 要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。 这些小应用之间通过服务完成交互和集成。
| 功能 | SOA | 微服务 |
|---|---|---|
| 组件大小 | 大块业务逻辑 | 单独任务或小块业务逻辑 |
| 耦合 | 通常松耦合 | 总是松耦合 |
| 公司架构 | 任何类型 | 专注于功能交叉团队 |
| 管理 | 着重中央管理 | 着重分散管理 |
| 目标 | 确保应用能够交互操作 | 执行新功能、快速拓展开发团队 |
1.2 分布式核心知识
1.2.1 分布式中的远程调用
在微服务架构中，通常存在多个服务之间的远程调用的需求。远程调用通常包含两个部分：序列化和通 信协议。常见的序列化协议包括json、xml、hession、protobuf、thrift、text、bytes等，目前主流的 远程调用技术有基于HTTP的RESTful接口以及基于TCP的RPC协议。
(1) RESTful 接口
REST，即Representational State Transfer(表现层状态转换)的缩写，如果一个架构符合REST原则，就称它为RESTful架 构。
资源（Resources）
所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图 片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它， 每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地 址或独一无二的识别符。REST的名称"表现层状态转化"中，省略了主语。"表现层"其实指的是"资 源"（Resources）的"表现层"。
表现层（Representation）
"资源"是一种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表 现层"（Representation）。比如，文本可以用txt格式表现，也可以用HTML格式、XML格式、JSON格 式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。URI只代表资源 的实体，不代表它的形式。严格地说，有些网址最后的".html"后缀名是不必要的，因为这个后缀名表示 格式，属于"表现层"范畴，而URI应该只代表"资源"的位置。
状态转化（State Transfer）
访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变 化。互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因 此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。 客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词： GET、POST、PUT、DELETE。它们分别对应四种基本操作：GET用来获取资源，POST用来新建资源 （也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。
综合上面的解释，我们总结一下什么是RESTful架构：
-
每一个URI代表一种资源；
-
客户端和服务器之间，传递这种资源的某种表现层；
-
客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。
(2）RPC协议
什么是RPC
RPC（Remote Procedure Call：远程过程调用 ） 一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC 框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式（TCP或者 UDP）、序列化方式（XML/JSON/二进制）和通信细节。开发人员在使用的时候只需要了解谁在什么 位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。
常见的RPC框架有：
-
OpenFeign
-
gRPC
Why Not HttpClient
可能你常听到什么什么之间是 RPC 调用的，那你有没有想过为什么要 RPC， 我们直接 WebClient HTTP 调用不行么？
其实 RPC 调用是因为服务的拆分，或者本身公司内部的多个服务之间的通信。
服务的拆分独立部署，那服务间的调用就必然需要网络通信，用 WebClient 调用当然可行，但是比较麻烦。我们想即使服务被拆分了但是使用起来还是和之前本地调用一样方便。
所以就出现了 RPC 框架，来屏蔽这些底层调用细节，使得我们编码上还是和之前本地调用相差不多。
并且 HTTP 协议比较的冗余，RPC 都是内部调用所以不需要太考虑通用性，只要公司内部保持格式统一即可。
所以可以做各种定制化的协议来使得通信更高效。
比如规定 yes 代表 yes的练级攻略，你看是不是更高效了，少传输的 5 个字。
就像特殊行动的暗号，高效简洁！
[ApiController]
public class CityController:ControllerBase {
private readonly ProvinceClient _provinceClient; // rpc 接口
public CityController(ProvinceClient provinceClient){
_provinceClient=provinceClient;
}
//获取所有省份
[HttpGet]
public Result<List<ProvinceDto>> GetProvinces(){
return _provinceClient.GetAll();
}
}
(3) 区别与联系
HTTP 和 RPC 其实是两个维度的东西， HTTP 指的是通信协议。
而 RPC 则是远程调用，其对应的是本地调用。
RPC 的通信可以用 HTTP 协议，也可以自定义协议，是不做约束的。
小结
-
公司内部服务的调用一般都用 RPC，而 HTTP 的优势在于通用，大家都认可这个协议。
-
三方平台提供的接口都是通过 HTTP 协议调用的。
1.3 CAP 理论
分布式系统（distributed system）正变得越来越重要，大型网站几乎都是分布式的。
分布式系统的最大难点，就是各个节点的状态如何保持一致。CAP理论是在设计分布式系统的过程中，处理数据一致性问题时必须考虑的理论。
一、什么是CAP理论
CAP即：
-
Consistency（一致性）
-
Availability（可用性）
-
Partition tolerance（分区容忍性）
这三个性质对应了分布式系统的三个指标： 而CAP理论说的就是：一个分布式系统，不可能同时做到这三点。如下图：
接下来将详细介绍C A P 三个指标的含义，以及三者如何权衡。
二 、 C、 A、P的含义
借用一下维基百科CAP理论一文中关于C、A、P三者的定义。
Consistency : Every read receives the most recent write or an error Availability : Every request receives a (non-error) response – without the guarantee that it contains the most recent write Partition tolerance : The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes
翻译一下就是： ①一致性：对于客户端的每次读操作，要么读到的是最新的数据，要么读取失败。换句话说，一致性是站在分布式系统的角度，对访问本系统的客户端的一种承诺：要么我给您返回一个错误，要么我给你返回绝对一致的最新数据，不难看出，其强调的是数据正确。
②可用性：任何客户端的请求都能得到响应数据，不会出现响应错误。换句话说，可用性是站在分布式系统的角度，对访问本系统的客户的另一种承诺：我一定会给您返回数据，不会给你返回错误，但不保证数据最新，强调的是不出错。
③分区容忍性：由于分布式系统通过网络进行通信，网络是不可靠的。当任意数量的消息丢失或延迟到达时，系统仍会继续提供服务，不会挂掉。换句话说，分区容忍性是站在分布式系统的角度，对访问本系统的客户端的再一种承诺：我会一直运行，不管我的内部出现何种数据同步问题，强调的是不挂掉。
三、权衡 C、A
之前提到,CAP理论说一个分布式系统不可能同时满足C、A、P这三个特性。那么我们就来分析C、A、P的权衡吧。
note：其实这里有个关于CAP理论理解的误区。不要以为在所有时候都只能选择两个特性。在不存在网络失败的情况下（分布式系统正常运行时），C和A能够同时保证。只有当网络发生分区或失败时，才会在C和A之间做出选择。
对于一个分布式系统而言，P是前提，必须保证，因为只要有网络交互就一定会有延迟和数据丢失，这种状况我们必须接受，必须保证系统不能挂掉。所以只剩下C、A可以选择。要么保证数据一致性（保证数据绝对正确），要么保证可用性（保证系统不出错）。
当选择了C（一致性）时，如果由于网络分区而无法保证特定信息是最新的，则系统将返回错误或超时。
当选择了A（可用性）时，系统将始终处理客户端的查询并尝试返回最新的可用的信息版本，即使由于网络分区而无法保证其是最新的。
四、C、A、P三者之间的冲突
本部分主要参考分布式CAP定理，为什么不能同时满足三个特性？
假设有两台服务器，一台放着应用A和数据库V，一台放着应用B和数据库V，他们之间的网络可以互通，也就相当于分布式系统的两个部分。
在满足一致性的时候，两台服务器(假设为N1,N2)的数据是一样的，DB0=DB0。在满足可用性的时候，用户不管是请求N1或者N2，都会得到立即响应。在满足分区容错性的情况下，N1和N2有任何一方宕机，或者网络不通的时候，都不会影响N1和N2彼此之间的正常运作。
图1中，用户通过N1中的A应用请求数据更新到服务器DB0，这时N1中的服务器DB0变为DB1，通过分布式系统的数据同步更新操作，N2服务器中的数据库V0也更新为了DB1（图2），这时，用户通过B向数据库发起请求得到的数据就是即时更新后的数据DB1。
上面是正常运作的情况，但分布式系统中，最大的问题就是网络，现在假设一种极端情况，N1和N2之间的网络断开了，但我们仍要支持这种网络异常，也就是满足分区容错性，那么这样能不能同时满足一致性和可用性呢？
假设N1和N2之间通信的时候网络突然出现故障，有用户向N1发送数据更新请求，那N1中的数据DB0将被更新为DB1，由于网络是断开的，N2中的数据库仍旧是DB0；
如果这个时候，有用户向N2发送数据读取请求，由于数据还没有进行同步，应用程序没办法立即给用户返回最新的数据DB1，怎么办呢？有二种选择，第一，牺牲数据一致性，响应旧的数据DB0给用户；第二，牺牲可用性，阻塞等待，直到网络连接恢复，数据更新操作完成之后，再给用户响应最新的数据DB1
配套视频链接：课程简介 (cctalk.com)
标签：体系,HTTP,调用,服务,第一章,RPC,分布式系统,架构 From： https://www.cnblogs.com/xuyubing/p/17902050.html