1.传统单体服务

什么是单体架构？

传统单体服务就是 所有功能模块，只有一套代码，并且都部署在同一台服务器上。表都放在同一个数据库中。

缺点

(1) 复杂性逐渐变高,代码量大，各模块关系错综复杂。
(2) 阻碍技术创新,不能根据不同的模块的特点，为不同模块做技术选型。
(3) 开发效率低，由于提前没有考虑公用性，难以共用功能模块。

• 所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断。
• 所有人都阶段性完成任务后，不影响要上线的功能，才能部署。

• 举个栗子，商城模块和活动模块都需要支付，但是由于两个模块的开发人员各自开发各自的，导致两者都重复造轮子，造成代码冗余，浪费时间，或者是商城已开发了支付，活动需要用商城的支付，此刻才想到共用的话，增加沟通成本，接口很可能会需要变动，也会导致牵一发而动全身，导致商城调用支付接口处变动。

(4) 无法按需伸缩。不能依据流量来布局，比如说，做集群，只能把整个项目集群，活跃度不高的模块就浪费资源了。
(5) 代码量大，部署速度会逐渐变慢。
(6) 由于耦合性太高，每次一点小的改动，都可能会导致其他模块受到影响，都需要重新对整个项目进行测试，部署和重启，而且还有可能会导致整个项目崩溃。

2.微服务架构模式

什么是微服务?

专注于单一责任的小型功能模块为基础，通过API相互通信的方式完成复杂业务系统搭建的一种设计思想。

为什么需要微服务?

传统架构　扩展性差，可靠性不高，维护成本高。

优点

• 每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
• 微服务能够被小团队单独开发。
• 微服务是松耦合，是有功能意义的服务，无论是在开发阶段还是在部署阶段，都是独立的。
• 微服务能够使用不同的语言开发。
• 微服务易于被一个开发人员理解，修改和维护。
• 微服务能根据不同的服务的流量等，来自定义服务配置。
• 易于和第三方集成。
• 每个微服务都能有自己独立的存储方式。
• 故障隔离。

缺点

• 分布式系统可能复杂，难以管理。
• 分布部署，跟踪问题难。
• 服务数量增加，管理复杂性增加。

需要考虑的问题

• 虽然单个微服务代码量小，易于修改和维护，但是系统复杂度的总量是没变的。一个系统被拆成零碎的微服务后，最后还要集成为一个完整的系统，也很复杂。
• 当微服务达到一个量级的时候，如何提供一个高效的集群通讯机制，就成了一个问题。
• 单个微服务拥有自己的进程，进程本身就可以动态的启停，为无缝升级打好了基础，但谁来启动和停止进程，什么时机，选择在哪台设备上做这件事才是升级的关键，需要强大的版本管理和部署能力。
• 多个相同的微服务可以做负载均衡，提高性能和可靠性。就需要考虑什么时候应该启动更多的微服务，多个微服务的流量应该如何调度和分发，这背后也有一套复杂的负载监控和均衡系统在起作用。
• 微服务的上线和下线是动态的，当一个新的微服务上线时，用户如何访问到新服务？这就需要一个统一的入口，新的服务可以动态的注册到这个入口上，用户每次访问时，可以从这个入口拿到所有服务的访问地址。这个统一的入口，也是需要系统单独提供的。
• 安全策略如何集中管理？系统故障如何快速跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？

3.单体和微服务的区别

概念

方面	单体	微服务
体积	大	小
职责	繁杂	单一
耦合度	高	松
独立部署运行和扩展	否	是
独立开发和演化	否	是
独立团队和自治	否	是

优缺点

方面	单体	微服务
开发效率	低	高
技术选型	不灵活	灵活
按需伸缩	不灵活	灵活
部署	不灵活	灵活
可维护性	难	易
可扩展性	低	高
稳定性	低	高

能看到这的都是真爱，打个赏呗=。=

---

上一篇：行香子（一叶舟轻）

下一篇：行香子（携手江村）