微服务架构学习与思考(05)：微服务架构适用场景分析

226 0 0

作者:九卷技术录--关注技术架构，管理，产品

微服务架构学习系列文章：

一、简述

在实际开发中，需要考虑多种因素，来决定采取哪种架构模式才适合当前业务发展情况。

毕竟微服务也不能“包治百病”，不要把它当做万能药。企业研发哪里得病了，觉得只要把“微服务”这服药给用上，就药到病除。哪有这么简单的事情。
微服务有它自身的特点，优点和缺点，有其适用范围，微服务并不能解决所有问题。

你需要综合考虑一些情况：

比如业务所处发展阶段：

刚开始探索
高速发展期
还是成熟期

业务的复杂度：

业务访问量是多还是少
用户量是多还是少

开发人员：

开发人员素质，是初级还是高级
开发人员的数量

产品的形态：

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
- 代码臃肿庞大，变得越来越臃肿
- 响应需求变化时间变长
- 交付时间变长
技术人员
- 有技术，有意愿
- 团队人数足够
业务发展期
- 刚创立公司初期
- 高速发展期
- 成熟期

最后：微服务架构不是银弹 。

[完]

内容来源于网络如有侵权请私信删除

文章来源: 博客园

原文链接: https://www.cnblogs.com/jiujuan/p/13762969.html

标签： C++ CPP C++语言开发

你还没有登录，请先登录或注册！

还没有人评论，欢迎说说您的想法！

微服务架构学习与思考(05)：微服务架构适用场景分析