目标系统架构演变，单体-分布式-微服务-中台
微服务架构核心解决，横向对比1.0、2.0、3.0
践行微服务架构，全组件解读！
也谈中台
单体架构Monolithic
单体应用时代：应用程序就是一个项目，在一个进程里面运行。
简单-省事儿
电商UI->（自营、秒杀、超市、生鲜、金融）->DB
弊端就是东西都堆在一起，不能满足大数据高并发的诉求，逻辑太多，很难升级。
业务演进推动技术的发展。
垂直拆分
垂直拆分，独立部署和维护，分而治之！
优势：
1.独立开发、独立维护、独立演化；
2.更好的利用资源；
劣势：
1.进程间数据同步，分家时断不掉联系的，联系就麻烦了；
2.分布式的代价，使用数据库时对数据进行加锁，数据更新事务的问题；
3.代码重复问题，如支付、用户管理等问题；
分布式的第一要务就是不要使用分布式。
分布式服务
分布式：多个进程协作完成一件事儿，多进程抽取公用服务，分布式完成功能。
分布式代价很高。
例如，自营服务调用用户服务、支付服务、日志服务等，依次顺序调用，如果对应服务失败是否需要回退数据，以及对应数据的处理逻辑是如何处理的。
分布式事务、分布式锁、服务注册、服务发现、服务安全、服务治理等等，多个问题都需要解决。
新的问题，也是会被解决的，问题都被解决后，分布式就成了常规手段，轻松的用来高并发，而且都不仅仅于此，包括故意分拆满足扩展性。
微服务架构
分布式用到走火入魔，就是微服务。
微服务架构（Microsercice Architecture）是什么？
微服务架构就是一个用分布式服务拆分业务逻辑，完成解耦的架构模式（架构风格）。
微服务肯定是分布式的一种，是在分布式技术成熟之后，然后把分布式当成解耦手段来架构系统，是因为拆分服务很细致。
一个项目：三层架构-UI/BLL/DAL
微服务就是把BLL的方法独立成一个服务去调用。
构建微服务架构，其根基是什么？
把方法都拆成独立服务了，怎么样保证项目是可用的呢？
1.保证服务的高可用；
2.服务的可伸缩性；
微服务架构的三个版本的区别也是解决上面两个特性：v1.0、v2.0、v3.0。
微服务架构核心
基于集群去完成高可用以及伸缩性，集群就是多台服务器都做相同的事情，构建集群。
必须解决以下几个问题：
1.服务发现，调用方如何发现服务？
2.负载均衡，如何调用服务？
集中式代理-Nginx-v1.0
基于Nginx负载均衡,v1.0
1.服务发现，调用方如何发现服务？
2.负载均衡，如何调用服务？
服务发现：Nginx通过人工配置，指定服务配置数据，完成服务发现，服务伸缩如何处理？需要修改配置文件重启。
不能实现自动扩张，可以自动减少，如果减少时会自动重启Nginx，其自身的属性。
服务调用：由Nginx决定，比较省心。
客户端嵌入-Consul-v2.0
服务注册，非人工，怎么找服务的问题，有客户端决定调用的服务实例。
1.负载均衡；
2.服务注册与发现；
3.健康检查；
功能强大，自动发现-自动下线。
客户端集成复杂，负载均衡在客户端实现。
网络的环境是非常复杂的，要以最坏的情况来考虑。
目前用的比较主流。
服务网络-Service Mesh-v3.0
v3.0用的不多，华为+为品味，主机+代理，lstio
边车模式，限流、熔断均在sidecar中实现。
MicroService发展
1.0 Nginx-服务注册/发现问题
2.0 自动注册发现，熔断/限流/降级等服务治理
3.0 Service Mesh
都在无止境的包一层，没有什么技术问题是包一层不能解决的，如果有，就再包一层。
微服务架构2.0-网关-Gateway
网关的位置就明白了，主要用于服务治理，可以缓存数据，路由映射，限流，熔断，超时，降级
不响应是为了更好的响应。
客户端该如何调用服务？
进程间通信-共享存储
Redis、队列、第三方存储
进程通信-服务通信
WebService、WCF、WebAPI
进程通信-RPC
.NET Core、gRPC
鉴权&授权
基于token的安全验证体系。
在网关中实现，JWT、Identity Server 4.
瞬态故障处理
Polly是一种.NET弹性瞬态故障处理库，允许我们以非常顺畅和线程安全的方式来执行如进行充实、断流、超时、故障恢复等策略。
分布式追踪Skywalking-全链路追踪
分布式追踪和APM的Server端，它将包含Collector、Storage、独立的Web UI，并使用Open Tracing规范来设计追踪数据。
ExceptionLess or ELK
ExceptionLess：开源的日志收集和分析框架，能为应用程序提供实时错误、特性和日志报告。
统一的配置中心
Apollo：配置管理平台，能够集中化管理应用不同环境、不用集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。
分布式锁
单进程下，多线程操作同一个对象，可以使用lock锁保证只有一个线程可以进入。
多线程（分布式）下，如何保证该对象在任意时刻只能一个线程进入呢？
变量A是由状态的，不同故武器进程内跨进程的互斥机制来控制其共享资源的访问，这就是分布式锁。
分布式事务
分布式事务指事务的操作位于不同的节点上，需要保证事务的 AICD 特性。
例如在下单场景下，库存和订单如果不在同一个节点上，就涉及分布式事务。
1.两阶提交-2PC
2.补偿事务-TCC
3.本地消息表（异步确认）
4.MQ-事务消息
本地消息表
本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性，并且使用了消息队列来保证最终一致性。
-
在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。
-
之后将本地消息表中的消息转发到 Kafka 等消息队列中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发。
-
在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。
容器化
Docker是一个开源的应用容器引擎，可以打包应用以及以来包到一个可移植的镜像。
Build once run any where.
容器编排K8S
管理应用的全生命周期的工具，从创建应用/部署，应用提供服务，扩容缩容，更新，都非常的方便，与Docker结合使用。
CI/CD