微服务架构学习与思考(05):微服务架构适用场景分析
微服务架构学习系列文章:
- 微服务架构学习与思考(01):什么是微服务?微服务的优势和劣势
- 微服务架构学习与思考(02):微服务实施的前提条件?有哪些问题需要思考?
- 微服务架构学习与思考(03):微服务总体架构图解
- 微服务架构学习与思考(04):微服务技术体系
- 微服务架构学习与思考(05):微服务架构适用场景分析
一、简述
在实际开发中,需要考虑多种因素,来决定采取哪种架构模式才适合当前业务发展情况。
毕竟微服务也不能“包治百病”,不要把它当做万能药。企业研发哪里得病了,觉得只要把“微服务”这服药给用上,就药到病除。哪有这么简单的事情。
微服务有它自身的特点,优点和缺点,有其适用范围,微服务并不能解决所有问题。
你需要综合考虑一些情况:
比如 业务所处发展阶段:
- 刚开始探索
- 高速发展期
- 还是成熟期
业务的复杂度:
- 业务访问量是多还是少
- 用户量是多还是少
开发人员:
- 开发人员素质,是初级还是高级
- 开发人员的数量
产品的形态:
- APP
- web
- 小程序
是否3者都有
等等都是需要综合考虑的因素。
二、微服务和单体优缺点对比分析
下面内容是对比微服务架构和单体架构的优缺点:
说明:√ - 优 , × - 劣
序号 | 对比项 | 微服务架构 | 单体架构 | 优劣评比 |
---|---|---|---|---|
1 | 调用难度 | API 接口调用 | 数据库共享或本地程序调用 | API都是远程调用,出问题情况更多,微服务:× 单体:√ |
2 | 系统设计-可扩展性 | 每个业务可以独立一个微服务,用api进行通信,可扩展性强 | 由于是一个单体应用,整个应用都在一起,耦合度高,可扩展性下降 | 微服务:√ 单体:× |
3 | 系统设计-可维护性 | 每个团队独立负责一个或者几个微服务,业务复杂度降低,可维护性高 | 所有开发人员都在一个单体上进行开发,所以业务整合在一起,可维护性差 | 微服务:√ 单体:× |
4 | 系统设计-高性能 | 一个微服务可能调用几个其他的微服务,网络通信变多,性能下降 | 在单体内进行通信,性能高 | 微服务:× 单体:√ |
5 | 业务开发复杂度 | 由于把单体拆分成多个微服务,业务复杂度也随着分解到多个服务中 | 在一个单体里,业务都糅合在一起,容易牵一发而动全身 | 微服务:√ 单体:× |
6 | 开发效率 | 早期设计和沟通的工作量加大,随着项目规模和时间的推移,效率变化不大 | 早期工作量小,随着项目规模和时间的推移,效率大幅度下降 | 随着时间复杂度上升:微服务 √,简单项目:单体 √ , 复杂项目:微服务 √ |
7 | 需求变更响应速度 | 各个微服务只负责自己的业务部分,独立变更,敏捷开发更好 | 单体变更,有可能牵一发而动全身,导致其他模块出事故 | 微服务:√ 单体:× |
8 | 运维难度 | 大系统拆分成多个小系统,导致系统变多,服务一多,部署和运维难度就加大,所以需要DevOps | 由于是单体,运维相对来说简单 | 微服务:× 单体:√ |
9 | 交付效率 | 拆分成多个小系统,小系统打包编译快,交付也随之变快。配合DevOps会更快 | 大单体比较大,编译打包慢,导致交付也慢 | 微服务:√ 单体:× |
10 | 服务治理 | 服务变多,治理复杂 | 单体应用治理简单 | 微服务:× 单体:√ |
11 | 业务复用性 | 微服务更好 | 单体复用性差 | 微服务:√ 单体:× |
12 | 代码复用性 | 可以用组件形式复用,微服务形式复用 | 一般是共享库形式复用 | 微服务:√ 单体:× |
13 | 开发成本 | 前后期开发成本一样 | 前期开发成本低,后期业务复杂度上来成本变高 | 一个变化的过程,前期:单体 √ 后期:微服务 √ |
14 | 职责划分 | 由于每个微服务由独立团队负责,职责划分明确 | 开发人员都在一个单体上开发,功能交叉,职责模糊,容易产生丢锅行为 | 微服务:√ 单体:× |
15 | 开发人数 | 由于划分为多个微服务,1个或几个微服务由独立团队负责,开发人数会上升 | 人数增加没有微服务那么明显 | 微服务:× 单体:√ |
16 | 风险 | 由于划分为多个独立的微服务,风险被分担给各个服务,控制在各个小系统内 | 单体系统是一个整体,一个小错误可能导致整个系统不可用,牵一发而费全身 | 微服务:√ 单体:× |
17 | 分布式开发情况 | 困难增加,比如分布式事务,分布式一致性,数据库拆分之后的联合查询 | 数据库拆分后的联合查询 | 微服务:× 单体:√ |
18 | 系统整体复杂度 | 整体复杂度变高,因为拆分微服务比较多 | 整体复杂度稍低 | 微服务:× 单体:√ |
从上面各项分析,可以看出,对于微服务和单体,各有优缺点。
业务简单项目:单体优势为开发效率、调用难度、服务治理、运维难度、开发成本。 比如刚开始展开业务,还不知道业务是否可行,需要验证业务模型时候,可以用单体快速简单开发验证业务模型,跑通业务模型。
业务复杂项目:微服务的优势就开始上升了。优势明显增多。但是治理复杂度也随着上升。
所以微服务也不是银弹,它也有很多缺点,所以它也有不适用的场景。
三、微服务适用场景
从上面的单体和微服务对比的优缺点分析来看,微服务架构也不是“包治百病”,它也有适用的场景。怎么判断这个适用场景?对着上面的项目对比来看,就可以判断当前项目是否适合微服务架构。这也是架构选型所要考虑的情况。
微服务适用场景也可以简化为下面:
- 响应需求变慢,需求开发时间变长。
- 交付的效率变差,bug数越来越多。
- 业务复杂度变高,应用达到3个或3个以上,或者模块达到5个或以上。
- 团队人数变多,开发至少有5人以上,运维至少2人。
- 项目需要长期迭代维护,至少一年以上。
上面只是为了判断简化对比项目,是一个简单模型,但请务必参考上面详细的对比项目来认真思考。
什么时候适合引入微服务的考量因素:
- 业务角度
- 业务需求开发是否经常延迟
- 产品交付是否能跟上业务发展
- 业务维护周期长
- 业务复杂度
- 业务量有多少
- 研发质量
- 代码是否因为修改而经常出现bug
- 代码臃肿庞大,变得越来越臃肿
- 响应需求变化时间变长
- 交付时间变长
- 技术人员
- 有技术,有意愿
- 团队人数足够
- 业务发展期
- 刚创立公司初期
- 高速发展期
- 成熟期
最后:微服务架构不是银弹 。
[完]
== just do it ==