单体架构的不足和解决方案(微服务)

2018/09 04 10:09

目录:


一、单体架构的优势

1、便于开发:只需要借助IDE的开发、调试功能即可完成

2、易于测试:只需要通过单元测试或者浏览器即可完成测试

3、易于部署:打包成单一可执行jar包,执行jar包即可完成部署


二、单体架构的不足

1、复杂性高

(1)代码难以理解

(2)难以理解导致代码质量低,复杂性进一步增加

(3)代码难以被修改和重构

2、交付效率低

(1)构建和部署耗时长,难以定位问题,开发效率低

(2)代码复杂和变更影响难以理解,需要数天完成全量测试

(3)全量部署耗时长、影响范围广、风险大、发布频率低

3、伸缩性(scalable)差

(1)单体只能按模块横向扩展,无法分模块 垂直扩展

(2)IO密集型模块和CPU密集型模块无法独立升级和扩容

4、可靠性差

(1)一个bug有可能引起整个应用的崩溃

5、阻碍技术创新

(1)受技术栈限制,团队成员使用同一框架和语言

(2)升级和变革技术框架变得困难

(3)尝试新语言变得困难


三、微服务架构介绍

1、什么是微服务架构

将单体应用拆分为多个高内聚低耦合的小型服务,每个小服务运行在独立进程,由不同的团队开发和维护,服务间采用轻量级通信机制,独立自动部署,可以采用不同的语言及存储


四、微服务的优势

1、易于开发与维护

(1)微服务相对小,易于理解

(2)启动时间短,开发效率高

2、独立部署

(1)一个微服务的修改不需要协调其他服务

3、伸缩性强

(1)每个服务都可以在横向和纵向上扩展

(2)每个服务都可按硬件资源的需求进行独立扩容

4、与组织结构相匹配

(1)微服务架构可以更好将架构与组织匹配

(2)每个团队独立负责某些服务,获得更高的生产力

5、技术异构性

(1)使用最合适该服务的技术

(2)降低尝试新技术的成本



五、伸缩立方与微服务拆分

1、X轴扩展

2、Z轴扩展

3、Y轴扩展

4、一个支付系统的简单微服务架构


六、微服务面临的挑战

1、服务拆分

(1)微服务拆分原则:领域模型、组织架构、康威定律、单一职责

(2)微服务拥有独立数据库

(3)微服务之间确定服务边界

2、数据一致性(最终一致性)

(1)可靠性事件模式

(2)补偿模式-saga模式

3、服务通信

(1)通信技术方案:RPC vs REST vs 异步消息

(2)服务注册和发现

(3)负载均衡

4、服务网关

(1)API Gateway(API 网关)

(2)为前端服务的后端(Backends For Forntends)

(3)身份认证、路由服务、流量控制、日志统计

5、高可观察

(1)健康监测、集中监控

(2)日志集合及检索

(3)分布式追踪

6、可靠性

(1)流量控制、超时控制

(2)舱壁隔离、熔断机制

(3)服务降级、幂等重试


七、微服务关注点全景图



八、微服务最佳实践

1、裁剪服务代码模块(代码脚手架 )

2、为微服务分配独立的数据库

3、如何对待共享库

4、稳固的持续集成和自动化部署流水线


九、单体架构向微服务迁移的时机



十、SOA vs 微服务

1、技术栈

(1)SOA:ESB、SOAP

(2)微服务:轻量级MQ、REST、RPC

2、数据拆分

(1)SOA:共享数据库

(2)微服务:一个服务一个数据库

3、服务粒度

(1)SOA:粒度比较粗,多个单体的组合

(2)微服务:粒度更小的服务

 

--转载请注明: https://www.guangboyuan.cn/%e5%8d%95%e4%bd%93%e6%9e%b6%e6%9e%84%e7%9a%84%e4%b8%8d%e8%b6%b3%e5%92%8c%e8%a7%a3%e5%86%b3%e6%96%b9%e6%a1%88%ef%bc%88%e5%be%ae%e6%9c%8d%e5%8a%a1%ef%bc%89/

发表回复

(必填)