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

一、简述

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

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

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

比如 业务所处发展阶段：

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

业务的复杂度：

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

开发人员：

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

产品的形态：

1. APP
2. web
3. 小程序
   是否3者都有

等等都是需要综合考虑的因素。

二、微服务和单体优缺点对比分析

下面内容是对比微服务架构和单体架构的优缺点：

说明：√ - 优 ， × - 劣

序号	对比项	微服务架构	单体架构	优劣评比
1	调用难度	API 接口调用	数据库共享或本地程序调用	API都是远程调用，出问题情况更多，微服务：× 单体：√