1.单架构到微服务
- 单架构如何进化为微服务架构
- 如何设计微服务系统
- 微服务架构的设计原则
- 什么是单块架构
- 请求到响应都是从到1的:用户==》1.表示层==》2.业务层==3.数据访问层==》数据库
- 典型的单块架构就是上述分层的,web(html,css,js),业务逻辑层(java,python,go),数据持久层(sql)
- 单架构,优点:功能划分清楚,层次关系良好,每一层独立,部署简单(一个包),技术单一(java,springBoot技术栈),用人成本低
- 缺点:功能太大,升级风险高,维护成本增加,交付周期长,可伸缩性变差,监控困难
2.如何将单块架构转为微服务架构
- 系统初始,都是内聚的,所有功能累加到一起,单体架构
- 以SOA为例
3.微服务架构的设计原则(颗粒度设计)
- 微服务设计:James Lewis和Martin Fowler,服务可以运行在进程中,可以如http交互,没有太大的技术关联,可以用不同的数据存储形式
- 拆分足够微,(亚马逊两个披萨原则,不能太小,管理成本)
- 轻量级通信,(微服务都是跨域,跨主机的,web服务,rest,rpc,同步用rest(http,格式用json或xml),异步用消息中间件)
- 领域驱动原则,(服务要体现领域业务模型,容易让团队理解上下文边界,一定要理解需求先,一定要深刻了解业务模型),就是我要跟领域专家达成一致
- 单一职责原则:(高内聚,低耦合,对其它服务的依赖要低,单一界限上下文)
6微服务拆分
- 举例说,SpringBoot,天气预报缺乏业务有效隔离,第三方采集接口协议变了怎么办??,改了这个代码必将影响整个应用,他们是杂在一起的
- 微服务的意义:
- 易于实现
- 利于维护
- 易于部署,轻量级的(SpringBoot都是内嵌容器的,tomcat容器)
- 易于更新,服务是隔离的
- 正向反馈闭环很快: 需求==》开发==》集成==》测试==》部署==》有问题就继续需求
- 微服务拆分方法:
- 横向拆分:数据采集,数据存储,数据查询,数据展示
- 纵向拆分:用户界面层,应用层,领域层,基础设施层;这已经架构了,比如java的包
- 使用DDD,驱动设计原则: 天气预报系统:天气数据采集界限(数据采集,数据存储),天气预报(数据展示),天气数据API(数据查询),城市数据API(数据查询)