一、简述
在实际开发中,需要考虑多种因素,来决定采取哪种架构模式才适合当前业务发展情况。
毕竟微服务也不能“包治百病”,不要把它当做万能药。企业研发哪里得病了,觉得只要把“微服务”这服药给用上,就药到病除。哪有这么简单的事情。
微服务有它自身的特点,优点和缺点,有其适用范围,微服务并不能解决所有问题。
你需要综合考虑一些情况:
比如 业务所处发展阶段:
- 刚开始探索
- 高速发展期
- 还是成熟期
业务的复杂度:
- 业务访问量是多还是少
- 用户量是多还是少
开发人员:
- 开发人员素质,是初级还是高级
- 开发人员的数量
产品的形态:
- APP
- web
- 小程序
是否3者都有
等等都是需要综合考虑的因素。
二、微服务和单体优缺点对比分析
下面内容是对比微服务架构和单体架构的优缺点:
说明:√ - 优 , × - 劣
序号 | 对比项 | 微服务架构 | 单体架构 | 优劣评比 |
---|---|---|---|---|
1 | 调用难度 | API 接口调用 | 数据库共享或本地程序调用 | API都是远程调用,出问题情况更多,微服务:× 单体:√ |