文章详情

短信预约-IT技能 免费直播动态提醒

请输入下面的图形验证码

提交验证

短信预约提醒成功

涵盖整个生命周期,微服务设计与治理的16条常用原则

2024-12-01 13:41

关注

这是我们对微服务进行架构设计过程中非常关注的两个问题。

本文对微服务的生命周期定义了七个阶段,如下图所示。

围绕这七个阶段总结了16条常用原则。

一、微服务规划

原则1:按照业务能力(business capabilities)来规划或拆微服务。

康威定律:Conway’s law: Organizations which design systems[…] are constrained to produce designs which are copies of the communication structures of these organizations.

(设计系统的组织,其产生的设计和架构等价于组织间的沟通结构。)

组织的沟通和系统的设计之间紧密相连,特别是复杂系统,解决好人与人的沟通才能有一个更好的系统设计。

《人月神话》中总结出了随着人员的增加沟通成本呈指数增长的规律:沟通成本 = n(n-1)/2。举例说明:

系统越复杂,人手越多,沟通成本也呈指数增长。因此,分而治之便是大多数公司选择的解决方案。分不同的层级,分不同的小团队,让团队内部完成自治理。

原则2: 按照领域驱动设计(Domain-Driven Design,DDD)来规划或拆解微服务。

领域驱动设计是微服务领域的热门话题,本文不展开说明,仅说明几点重要事项:

原则2与原则1的区别在于,原则1关注组织架构领域,原则2更偏向软件工程设计领域。

二、微服务设计

原则3:微服务的设计应该遵循「单一职责」原则。

所谓单一职责原则,就是对一个服务而言,它的功能要单一,只做与它相关的事情。在微服务的设计过程中要按职责进行设计,彼此保持正交,互不干涉。

什么样的单一领域对象的单一职责微服务才是有价值的?就是不断有业务变化,能够维持业务持久性,有业务生命力的领域对象。举例来说:

那么就很有价值独立为一个微服务,实现独立演进、个性化的弹性伸缩。

所以,我们在进行微服务设计时,要能够分析、预测出需求变化的点在哪里?高并发的点在哪些?数据增长的位置在哪里?与DDD分析相结合,找出最有价值的那个单一职责,进行合理、适度的领域、子领域、有界上下文分解,才能更好的应对复杂的业务、不断变化的业务。

原则4: 微服务的设计应该遵循「高内聚」原则。

过度追求「单一职责」,或者拆分微服务过细,往往会带来不良后果。微服务的设计并不是越细越好,过度拆分会导致调用性能变差、数据一致性难以保障、系统可用性降低等问题。

因此,「高内聚」原则要求:

原则5:微服务的设计应该遵循「低耦合」原则。

三、微服务实现

原则6:服务无状态。

什么是「状态」?如果一个数据需要被多个服务共享,才能完成一笔交易,那么这个数据被称为状态。

依赖这个「状态」数据的服务被称为有状态服务,反之称为无状态服务。

「无状态」原则并不是说在微服务架构里就不允许存在状态,而是要把有状态的业务服务改变为无状态的计算类服务,那么状态数据也就相应的迁移到对应的“有状态数据服务”中。

场景说明:例如我们以前在本地内存中建立的数据缓存、Session缓存,到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储,让业务服务变成一个无状态的计算节点。迁移后,就可以做到按需动态伸缩,微服务应用在运行时动态增删节点,就不再需要考虑缓存数据如何同步的问题。

只有服务无状态,才能实现快速弹性扩缩容,应对流量峰谷。

原则7:服务高可用。

接入高可用中间件(如sentinal),实现限流、熔断、降级,增强可用性。

原则8:服务可观测。

除了默认系统监控外,微服务需要梳理并定义必要的「业务监控指标」。

原则9:服务配置可管理。

微服务相关配置需要统一接入配置中心进行管理、控制。

四、微服务调用

原则10:避免「分布式大单体」。

只做单向调用,避免循环调用。

多个服务循环依赖调用形成集中式“分布式大单体”,违背微服务的原则。

原则11:异步解耦。

按需接入消息队列,实现「依赖解耦」、「流量削峰」

原则12:引入BFF层,降低客户端与后端微服务之间的耦合。

尽量设计BFF层,把前端的特殊需求交给BFF层,使后端服务逻辑具有高内聚、高复用性的精简核心逻辑。

五、微服务发布

原则13:服务发布遵循安全发布三板斧。

保证「可灰度」、「可监控」、「可回滚」。

六、微服务治理

原则14:正视「架构腐化」,遵循「持续演进」原则。

「架构腐化」的常见场景:

原则15:参考「AKF扩展立方」模型,服务除了「水平扩容」外,还可以考虑「功能拆分」或者 「数据分区」。

1)X轴:服务和数据的水平扩容

「水平扩容」比较容易理解,直白点说就是加机器。根据AKF模型,除了加机器外,我们还可以考虑「功能拆分」或者 「数据分区」。

2)Y轴:功能/业务拆分

「功能拆分」相对复杂,一般包括几种模式:

3)Z轴:沿客户边界的服务和数据分区

「数据分区」往往指的是数据库层面。需要引入数据库中间件,像 sharding-jdbc、mycat 等,在数据层面需要配置相应的分片逻辑。正确的拆分对提高系统的容量有很大的帮助,失败的拆分可能会造成热点集中,得不偿失。常用的分区逻辑包括 按照时间分区、按照用户id取模分区等。

七、微服务下线

原则16:对于「废弃服务」,需要做好「下线」工作,包括服务下线、存储释放等。

清理无效代码、环境,减少维护成本。同时释放资源,节约成本。

八、总结

架构师在进行微服务设计和微服务治理时,可以围绕微服务生命周期的七个阶段展开。

本文总结了16条常用原则,希望能提供一些思路和启发。

来源:阿丸笔记内容投诉

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题
  • 2024年上半年信息系统项目管理师第二批次真题及答案解析(完整版)

    难度     813人已做
    查看
  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看
  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看
  • 2024年上半年软考高项第一、二批次真题考点汇总(完整版)

    难度     435人已做
    查看
  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机
位置:首页-资讯-后端开发
咦!没有更多了?去看看其它编程学习网 内容吧
首页课程
资料下载
问答资讯