微服务架构学习系列文章：
- 微服务架构学习与思考(01)：什么是微服务？微服务的优势和劣势
- 微服务架构学习与思考(02)：微服务实施前有哪些问题需要思考？
- 微服务架构学习与思考(03)：微服务总体架构图解
- 微服务架构学习与思考(04)：微服务技术体系
- 微服务架构学习与思考(05)：微服务架构适用场景分析
一、简述
在实际开发中，需要考虑多种因素，决定采取哪种架构模式才适合当前业务发展情况。
比如：业务发展阶段-刚开始探索还是高速发展时期，业务的复杂度，业务访问量是多还是少，用户量是多还是少，开发人员的组成情况，开发人员的数量 等等都是需要考虑的因素。
二、微服务和单体优缺点对比分析
下面内容是对比微服务架构和单体架构的优缺点：
说明：√ - 优 ， × - 劣
| 序号 | 对比项 | 微服务架构 | 单体架构 | 优劣评比 |
|---|---|---|---|---|
| 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
- 代码臃肿庞大，变得越来越臃肿
- 响应需求变化时间变长
- 交付时间变长
- 技术人员
- 有技术，有意愿
- 团队人数足够
最后：微服务架构不是银弹 。
[完]