欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页  >  IT编程

微服务拆分,选型与演进

程序员文章站 2022-04-15 19:55:12
微服务拆分原则在微服务拆分中,核心需求在于拆开的微服务之间的联系越少越好,数据交互也是越少越好。因为微服务之间的数据一致性非常难处理,如果一致性方面的问题很少,整体做起来就比较简单了......

微服务拆分,选型与演进

微服务拆分原则

在微服务拆分中,核心需求在于拆开的微服务之间的联系越少越好,数据交互也是越少越好。因为微服务之间的数据一致性非常难处理,如果一致性方面的问题很少,整体做起来就比较简单了。

微服务架构选型

微服务架构的选型也是一个让人比较纠结的事。选择开源技术时,社区的活跃度是非常重要的参考。

第二个选型原则:一定要满足需求,这是要重点考虑的。

第三点原则是掌控能力,假设一个框架是用 C 语言写的,整个团队没有懂 C 语言的人,这样肯定不行。

因此,微服务架构选型需要考虑:社区活跃度、需求满足度、掌控能力这三方面。

微服务架构演进方式

再来说说微服务架构的演进。微服务是长出来的,而不是设计出来的。完全架空地去做一套新系统当然可以做好微服务架构,但很多时候我们没有这种条件,都是在一个已有的系统里去做。

因此,架构演进方式就是:有了新需求,做一个独立的微服务,慢慢做成服务化互相调用,然后把数据切分过来。

但数据切分也不是一次就做完了,而是数据先在存在于新老系统中,两边保持一致,逐渐再迁移至新系统。

最后的结果可能是老系统中还有残留,但是在它周边的很多新需求,全都是通过一个个独立微服务做出来的,这就是微服务长出来的方式。

在项目落地中,这种架构演进方式还是有很多风险的,也经常有客户采用完全中心开发的方式做微服务,比较简单纯粹,但需要多花很多成本。

微服务是需要大平台支撑的

微服务革新了软件的生产过程,包括开发、测试和部署各个阶段。但服务的切分并不是要遵守单一原则,因为未来的服务不可能完全垂直切分。

从另一个角度看,微服务的过程其实也是工业化的工程,每个微服务都是生产线上的一个零件,但要注意,零件的组装和拼接难度更大,所以在谈论微服务时一定要注意,它需要一个大平台支撑。

比如有自己的企业级 PaaS 整体解决方案,整个 PaaS 平台底层是容器平台,它是 PaaS 中的一个基础设施,再上一层有应用的开发管理,应用的部署上线,以及应用的运行管理和开发管理。

微服务的开发框架就跟开发管理相关。微服务咨询,这属于解决方案的一部分,包括了微服务拆分设计的咨询,以及微服务框架选型和微服务的开发指导,这两者属于开发过程管理。

对于微服务的发布上线和微服务运行的管理,还有服务治理,监控和服务治理是云平台管理的重要方面。微服务上线是容器平台的事情,微服务运行管理就涉及到服务治理。

除了上述四个方面之外,企业提升微服务落地的能力,最重要的是整个团队要达成共识。现在开发团队经常会听到两种声音,一是希望借助新技术,发展新东西,二是希望按部就班,不做改变。前者和微服务是比较匹配的,后者对微服务是一种阻力。

所以首先需要团队达成共识,如果第一个微服务试点项目失败,可能之后很长一段时间内都没有机会落地微服务了。其次,团队要做好心理准备与知识储备,因为微服务对开发、测试人员都带来了挑战,如果没有准备好,可能就需要花更多时间。

总之,微服务之路的想法是好的,但是在追赶微服务浪潮之前,企业和团队应该负责任地考虑,做好权衡取舍,切忌盲目跟风。

微服务架构首先要关注的不是概念与技术框架,而是服务的边界、职责划分,划分错误就会陷入大量服务间的相互调用和分布式事务中,这种微服务实践带来的不是便利而是麻烦。

本文地址:https://blog.csdn.net/peter7_zhang/article/details/107373880

相关标签: 分布式