3.从单架构到微服务

1.单架构到微服务

1. 单架构如何进化为微服务架构
2. 如何设计微服务系统
3. 微服务架构的设计原则
   
   • 什么是单块架构
4. 请求到响应都是从到1的：用户==》1.表示层==》2.业务层==3.数据访问层==》数据库
5. 典型的单块架构就是上述分层的，web（html，css,js），业务逻辑层(java,python,go)，数据持久层(sql)
6. 单架构，优点：功能划分清楚，层次关系良好，每一层独立，部署简单（一个包），技术单一（java，springBoot技术栈），用人成本低
7. 缺点：功能太大，升级风险高，维护成本增加，交付周期长，可伸缩性变差，监控困难

2.如何将单块架构转为微服务架构

1. 系统初始，都是内聚的，所有功能累加到一起，单体架构
2. 以SOA为例

3.微服务架构的设计原则（颗粒度设计）

• 微服务设计：James Lewis和Martin Fowler，服务可以运行在进程中，可以如http交互，没有太大的技术关联，可以用不同的数据存储形式
  
  1. 拆分足够微，（亚马逊两个披萨原则，不能太小，管理成本）
  2. 轻量级通信，（微服务都是跨域，跨主机的，web服务，rest，rpc，同步用rest（http，格式用json或xml），异步用消息中间件）
  3. 领域驱动原则，（服务要体现领域业务模型，容易让团队理解上下文边界，一定要理解需求先，一定要深刻了解业务模型），就是我要跟领域专家达成一致
  4. 单一职责原则：（高内聚，低耦合，对其它服务的依赖要低，单一界限上下文）

6微服务拆分

• 举例说，SpringBoot，天气预报缺乏业务有效隔离，第三方采集接口协议变了怎么办？？，改了这个代码必将影响整个应用，他们是杂在一起的
• 微服务的意义：
  
  1. 易于实现
  2. 利于维护
  3. 易于部署，轻量级的（SpringBoot都是内嵌容器的，tomcat容器）
  4. 易于更新，服务是隔离的
• 正向反馈闭环很快： 需求==》开发==》集成==》测试==》部署==》有问题就继续需求
• 微服务拆分方法：
  
  1. 横向拆分：数据采集，数据存储，数据查询，数据展示
  2. 纵向拆分：用户界面层，应用层，领域层，基础设施层；这已经架构了，比如java的包
  3. 使用DDD，驱动设计原则： 天气预报系统：天气数据采集界限（数据采集，数据存储），天气预报（数据展示），天气数据API（数据查询），城市数据API（数据查询）