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(数据查询)
阅读更多
上一篇2bug,天气预报乱码问题
下一篇4.天气预报系统的微服务架构设计
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭