一：架构演变过程

一、单体架构

单体架构存在的问题：

1、并发量的问题
2、隔离性差：所有的业务共享资源，一旦某个业务出现问题，可能会连带其他的业务不可用
3.协同效率低：所有业务一起上，如果出问题了就回滚，解决完，在上一次

优点：

1、开发成本低 性能高（没有通信，不走网络）
2、运维成本低（这个不像微服务架构一样模块会调模块，当运维发现这个模块出了问题，就有可能是调了其他模块）

二、单体集群架构

集群的问题：

1、可以局部的解决并发量的问题，但是并不完美
2、资源隔离的问题仍然存在

三、分布式集群架构

优势：

1、业务隔离：按照模块进行拆分，分布到不同的机器上，处理不同的业务，这样如果某个业务有问题，不会影响其他业务的正常工作。
2、可以很灵活的根据业务的并发大小，弹性的调整每个业务的集群规模
3.迭代快 稳定性高 故障范围小 易扩展（比如单体的要扩展服务，他是扩展整体的，分布式就是扩展自己想要的模块）

问题：

1、模块和模块之间完全没有联系吗？- 不是，实际开发过程中，往往很多模块之间是需要互相依赖和调用的，这里就牵扯了服务间的互调（Http协议）
2、开发成本高（调各种基础组件） 基础设施依赖高 维护复杂（服务节点变多，排查路线边长） 响应慢

四、微服务架构体系（Dubbo、SpringCloud）

大致的微服务架构分布图

微服务架构思考：
好处

1、服务边界清晰
2、 开发相对独立
3、提升系统稳定性
4、扩展能力强

不足

1、链路变长、定位问题困难
2、系统运维成本高
3、对服务治理挑战大

4.1微服务系统及涉及技术点剖析

分布式架构技术挑战

1、节点故障：每台机器部署的多个节点，如果有一个节点挂了，需要知道哪台节点挂了，节点之间是怎么调用的，这就要流量控制或者性能监控平台了就可以针对性的恢复。如果线上几千台节点靠人工去发现问题就不太现实了所以需要监控体系。
2、机器性能差异：机器能坑的流量，处理请求不一样，部署的没那么好，怎么让流量适应，那么权重，路由去解决。
3、网路不可靠性：网络抖动，那么是就要有尝试机制，偶尔的抖动处理掉。
4、基础组件需求：那么上面三条就是基础组件完成的。
5、服务治理复杂度：

核心组成

1、运行环境：是跑在物理机上：如果有个节点挂了，做容错我就不把流量分配给他了，活了在给你；但是在云上就是挂一个在起一个节点ip就不一样，就必须强依赖注册中心。还有虚拟机上还是dockers上，
2、基础设施：比如网关我的流量不是直接打到网关的，一个http请求起码先走dns把ip拿到，拿到ip去访问那么这个ip是ngis的ip嘛。ngis如何做高可用，ng把流量打到网关。ng怎么做多个节点，实现高可用，还有cdn==静态资源在全国有边缘站，这样拿去静态资源就比较快，没有cdn如果静态资源在存储的比较远，那你拿取就比较慢。
3、模块划分
4、存储资源：不同的数据库还有不同的缓存
5、基础组件：
6、测试运维

衡量标准

1、可用性：
2、性能：取决代码质量
3、吞吐量
4、扩展性：无状态，或者状态转移，数据库扩展那就是分库分表会带来分布式问题，分布式数据库就可以不用做数据的迁移，redis的扩展。百万并发指的是扩展性你坑并不是指定的是架构
5、一致性

主要技术点

1、负载均衡：lv到ng到gatway都要负载均衡
2、session管理
3、通讯、rpc
4、服务注册与发现
5、消息队列
6、配置中心
7、分布式锁
8、缓存/分布式缓存
9、固化存储/分布式存储 tidb ： newsql=kv+sql ;kv有很好的扩展，MySQL扩展性差他要数据迁移。kv查询不太友好，只能靠api。newsql就实现了很好的扩展性kv又有很好的查询，他是底层存储用kv，然后上层用mysql请求兼容。那吞吐量，计算过谁保证，可以都是由sql解决

五、转转 二手平台业务架构演进案列

运营活动全在logic风险特别高，通过mq把他们分开，主业务分主业务，运营业务分运营活动

商品中心那一块就像中台一样手机和母婴有公共的业务下沉

六、分布式系统架构技术选型

6.1、服务网关选型

6.2、监控平台选型

6.3、rpc框架选型

6.4、消息队列选型

6.5、配置中心选型

6.6、注册中心

6.1：CAP理论
CAP理论是分布式架构中重要理论

一致性(Consistency) (所有节点在同一时间具有相同的数据) 可用性(Availability)
(保证每个请求不管成功或者失败都有响应) 分隔容忍(Partition tolerance)
(系统中任意信息的丢失或失败不会影响系统的继续运作)