【微服务架构】微服务架构与传统单体架构的区别
系统架构遵循的三大原则提升用户体验:提升用户体验,减少用户流失提高敏捷性:及时响应业务需求,促进企业发展降低成本:降低增加产品、客户或业务方案的成本传统单体架构先来看看传统单体项目架构图从微服务架构图得出如下结论:传统的单体应用架构功能集中,代码和数据中心化,一个发布包部署后运行在同一个进程中的应用程序。复杂性高:由于是单个归档文件,所以整个项目文件包含的模块非常多,导致模...
·
系统架构遵循的三大原则
- 提升用户体验:提升用户体验,减少用户流失
- 提高敏捷性:及时响应业务需求,促进企业发展
- 降低成本:降低增加产品、客户或业务方案的成本
传统单体架构
先来看看传统单体项目架构图
从单体应用架构图得出如下结论:
- 传统的单体应用架构功能集中,代码和数据中心化,一个发布包部署后运行在同一个进程中的应用程序。
- 复杂性高:由于是单个归档文件,所以整个项目文件包含的模块非常多,导致模块的边界模糊、依赖关系不清晰、代码的质量参差不齐,混乱的堆在一起,使得整个项目非常复杂。以致每次修改代码,都非常小心,可能添加一个简单的功能,或者修改一个Bug都会带来隐藏的缺陷。
- 技术债务:随着时间的推移、需求的变更和技术人员的更替,会逐渐形成应用程序的技术债务,并且越积越多。
- 扩展能力受限:单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。
微服务架构
再来看看微服务架构图
从微服务架构图得出如下结论:
- 微服务把每一个职责单一的功能放在一个独立的服务中 。
- 每个服务有多个实例在运行,每个实例可以运行在容器化平台内,达到平滑伸缩的效 果,单个微服务启动较快。
- 每个服务应该有自己的运营平台,以及独享的运营人员,这包括技术运维和业务运营人 员:每个服务都高度自治,内部的变化对外透明。
- 易于开发和维护:一个微服务只会关注一个特定的业务功能,所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
- 局部修改容易部署:单体应用只要有修改,就得重新部署整个应用。微服务解决了这样的问题。一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。
- 技术栈不受限制:在微服务架构中,可以结合项目业务及团队的特点,合理的选择技术栈。
更多推荐
已为社区贡献1条内容
所有评论(0)