ASP.NET CORE 微服务架构---------------我的基础认知

1.什么是是架构：系统的结构

什么是系统：一组关联的个体共同完成单个个体不能完成的任务的一组集合；

什么是结构：系统内部各个组件之间能够进行组成就是结构；

架构：  

1.系统各个组件

2.各个组件能够合作

2.什么是微服务：只能提供一项功能的服务就是 微服务

微服务特征

1.单一职责原则

2.升级简单和扩展轻松

3.独立性强

4.健壮性

3.微服务解决的问题：

1.解决并发量问题

2.解决数据量问题

3.解决业务量问题

4.解决团队量问题

 

 

 

 

应用服务集群解决了并非量的问题 但是数据瓶颈

 

 

 

 

 解决了数据量和并发量 如果并发量持续增大 网络IO也是一个瓶颈 我没将解决减少Io 假如Redis缓存

 

 

 当并发量持续增加 超过了阈值 异步架构来了

 

 

 到目前为止 能解决大并发量的问题了 但随着业务量的增大 功能模块的维护量增加 团队量增大 使得系统升级成本高 维护成本大的问题

升级缓慢  模块与模块之间相互影响  业务量 团队量增加

再次空间换时间：SOA面向服务架构

 

 

 ESB企业服务总线的缺陷

1.ESB协议多 维护复杂

2.服务拆分颗粒度不明确，服务没有大小和具体的规范，不利于团队管理

3.数据都存在同一个数据库，导致各个模块数据之间相互影响

为何解决以上的问题 微服务架构SOA的巅峰  满足 并发量 数据量 团队两 业务量

 

 

 4.微服务架构的缺陷：

1复杂性变高 

     1.1 系统不稳定

     1.2维护量增大

5.如何实践微服务架构

1.微服务的拆分

2.微服务的使用时机

3.微服务设计模式

4.微服务内部结构

5.1.1

 

 

 x：并发量 ---》水平扩展集群.

z：数据量 分库分表 主从复制

y：业务量 微服务架构

5.1.2微服务主要解决业务量的问题 如何将业务拆分

4个层面的拆分

1.系统层面

 

 

 

 

 

 

2.业务功能层面

 

 

3.功能层面

4.读写层面

 

 按照以上的拆分方法会拆分庞大的微服务体系 这就是 拆分没有银弹原则（银弹《一个方案可以解决所有问题》）并不是拆分就能解决 所以微服务拆分需要拆分时机

5.2.1 拆分时机 根据团队量进行适当拆分 一个微服务三个人维护或者 1个人一个微服务

我的总结：1.微服务拆分必须参考公司人员，公司资源

 2.公司人越多，拆分越细 反之越粗 粗细取决去 四个层面

原则就是--------- 设计的微服务架构 要有足够的灵活和扩展  预留拆分 一步一步按照需求拆分

5.3.1 微服务架构设计模式 ------聚合设计模式

实现简单 通讯高效 在于解耦与扩展