微服务架构风格可以降低系统的复杂度吗

2023-05-25 综合 27阅读
 在实施微服务架构改造之前,我们的产品线遇到一个很大挑战,就是需求的交付周期越来越短,采用的帆隐卜传统MVC单体携胡架构越来越难满足特性快速交付和上线的需求。传统的电信项目,团队规模往往都非常大,甚至会跨地域。跨团队、跨地域的分布式协同开发,代码的重用和共享是个难题。   例如我们的支付功能需要新增一个限额保护, 短短十几行代码的一个小需求,评估之后竟态穗然需要9个星期才能上线。原因就是限额保护功能需要同时在9个不同的功能模块中修改, 新增900多个测试用例用来做全量的回归测试,示例如下:      通过对已有的MVC单体架构进行分析,我们发现主要存在如下几个问题: 研发成本高:代码重复率高,需求变更困难,无法满足新业务快速上线和敏捷交付。 测试、部署成本高:业务运行在一个进程中,因此系统中任何程序的改变,都需要对整个系统重新测试并部署。 可伸缩性差:水平扩展只能基于整个系统进行扩展,无法针对某一个功能模块按需扩展。 可靠性差:某个应用BUG,例如死循环、OOM等,会导致整个进程宕机,影响其它合设的应用。 代码维护成本高:本地代码在不断的迭代和变更,最后形成了一个个垂直的功能孤岛,只有原来的开发者才理解接口调用关系和功能需求,新加入人员或者团队其它人员很难理解和维护这些代码。 依赖关系无法有效管理:服务间依赖关系变得错踪复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整的描述应用的架构关系。
声明:你问我答网所有作品(图文、音视频)均由用户自行上传分享,仅供网友学习交流。若您的权利被侵害,请联系fangmu6661024@163.com