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

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

一、简述

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

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

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

比如 业务所处发展阶段：

  1. 刚开始探索
  2. 高速发展期
  3. 还是成熟期

业务的复杂度：

  1. 业务访问量是多还是少
  2. 用户量是多还是少

开发人员：

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

产品的形态：

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

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

[完]

posted @ 2020-10-02 22:29  九卷  阅读(2814)  评论(1)  编辑  收藏  举报