【微服务架构】微服务架构与传统单体架构的区别

系统架构遵循的三大原则

        -- 提升用户体验：提升用户体验，减少用户流失

        -- 提高敏捷性：及时响应业务需求，促进企业发展

        -- 降低成本：降低增加产品、客户或业务方案的成本

传统单体架构

        先来看看传统单体项目架构图

        

传统单体架构图

从微服务架构图得出如下结论：

        -- 传统的单体应用架构功能集中，代码和数据中心化，一个发布包部署后运行在同一个进程中的应用程序。

        -- 复杂性高：由于是单个归档文件，所以整个项目文件包含的模块非常多，导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐，混乱的堆在一起，使得整个项目非常复杂。以致每次修改代码，都非常小心，可能添加一个简单的功能，或者修改一个Bug都会带来隐藏的缺陷。

        -- 技术债务：随着时间的推移、需求的变更和技术人员的更替，会逐渐形成应用程序的技术债务，并且越积越多。

        -- 扩展能力受限：单体应用只能作为一个整体进行扩展，无法根据业务模块的需要进行伸缩。

微服务架构

        再来看看微服务架构图

微服务架构

从微服务架构图得出如下结论：

        -- 微服务把每一个职责单一的功能放在一个独立的服务中 。

        -- 每个服务有多个实例在运行，每个实例可以运行在容器化平台内，达到平滑伸缩的效 果，单个微服务启动较快。

        -- 每个服务应该有自己的运营平台，以及独享的运营人员，这包括技术运维和业务运营人 员：每个服务都高度自治，内部的变化对外透明。

        -- 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务相对简单。

        -- 局部修改容易部署：单体应用只要有修改，就得重新部署整个应用。微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。

        -- 技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。