单体架构--->SOA(面向服务的架构，多机器处理)-->ESB(加入集群总线技术的SOA服务结构)----->微服务架构（服务网关，服务治理，服务之间负载均衡，服务注册和发现组成的SOA服务）---->数据中台思想（基于微服务，在业务流程中增加通用数据处理综合层次结构）
主要是从单个到多个，多个初步协作，多个中间协作限流安全，从业务处理过程中增加一层。
微服务：
微服务按照数据业务关系，对于原先大的一个统一的web系统进行拆分，拆分成为多个小的web系统。
优点：带来单个业务点，单个开发，单个上线。
缺点: 带来业务复杂度，整体项目的维护成本提高。
SOA和RestFull说明
SOA和RestFull一样不是一种技术约束，是一种提供接口内容的规范。
SOA: 首先约定你的web 项目需要有一个统一命名的接口，去查询到你的web服务有什么样的接口服务和接口服务的参数类型。。。。告诉别人你的web服务器上的服务内容。
RestFull风格的服务在SOA的服务基础之上约定内容和形式更多。约定接口URL的定义形式，URL的定义需要能够体现你的服务器上能够提供资源对应。
SOA和RestFull规范上来说，都是想在约定基础上，让别人跟清楚方便的理解你的web服务能力和怎么使用。
服务规范更好，不是很符合的情况下，可以在进行调用接口说明。当前有的Sweeger接口文档浏览等。
当前微服务的架构
基于SpringCloud 的微服务快速搭建。
基于dubbo的微服务架构。
基于微服务架构的整个系统更复杂：
涉及到多个进程，原先JAVA技术中的基于单个JVM实现的锁，对象调用技术不再试用。所以有了远程过程调用RPC和分布式锁。
分布式事务
2PC：两个阶段提交分布式事务，预提交事务主要进行事务锁定，事务的redo的log和undo的log的写入，提交阶段进行事务提交，释放锁。容易造成锁无法释放，阻塞，数据不一致问题。
3PC：预处理，预提交，提交，在预处理阶段保证协调节点与处理节点连通，切协调节点能够处理数据。预提交阶段进行redo和undo的写入，对于数据进行处理。提交阶段，对于数据进行提交。
TCC：分为try，cancel，commit 不基于数据库的事务，在程序处理中，保证数据的正确性。需要提供try接口锁定资源，cancel进行取消任务，commit进行提交处理。需要注意cancel接口允许在try之间调用。
当前主要的分布式事务的解决方案：
阿里开源的Seata：
历史：XTS->DTX->TXC->GTS->Fescar->Seata
官网：http://seata.io/en-us/docs/user/quickstart.html
LNC:
https://blog.csdn.net/baidu_36415076/article/details/79599619
https://github.com/codingapi/tx-lcn/wiki/zh_home
分布式锁：参考分布式集群中分布式锁
微服务注册方法：Spring Cloud Consul，alibaba 的nacos
微服务的网关：SpringCloud gatway（推荐），zuul，niginx
微服务的配置中心：Spring Cloud Consul Nacos
微服务的负载均衡：Spring Cloud Ribbon
微服务限流：
微服务安全认证：
微服务运行监测：
服务全量链路追踪：
服务端的C10K问题，是指服务端同时处理10000个请求连接时候，性能耗尽的问题。当前已经不存在，当前C1000K问题。
https://www.cnblogs.com/wenyule/p/14019212.html