架构师进阶,微服务设计与治理的16条常用原则-创新互联


今天将从存储的上一层「服务维度」学习架构师的第二项常用能力 —— 微服务设计与治理。

创新互联建站一直在为企业提供服务,多年的磨炼,使我们在创意设计,成都营销网站建设到技术研发拥有了开发经验。我们擅长倾听企业需求,挖掘用户对产品需求服务价值,为企业制作有用的创意设计体验。核心团队拥有超过十载以上行业经验,涵盖创意,策化,开发等专业领域,公司涉及领域有基础互联网服务IDC机房托管app软件定制开发、手机移动建站、网页设计、网络整合营销。

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

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

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

1、微服务规划
原则 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、微服务设计

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

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

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

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

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

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

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

3、微服务实现
原则 6:服务无状态。
什么是「状态」?如果一个数据需要被多个服务共享,才能完成一笔交易,那么这个数据被称为状态。

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

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

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

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

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

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

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

4、微服务调用
原则 10:避免「分布式大单体」
只做单向调用,避免循环调用。

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

原则 11:异步解耦。
按需接入消息队列,实现「依赖解耦」、「流量削峰」

原则 12:引入 BFF 层,降低客户端与后端微服务之间的耦合
尽量设计 BFF 层,把前端的特殊需求交给 BFF 层,使后端服务逻辑具有高内聚、高复用性的精简核心逻辑。

5、微服务发布
原则 13:服务发布遵循安全发布三板斧
保证「可灰度」、「可监控」、「可回滚」。

6、微服务治理
原则 14:正视「架构腐化」,遵循「持续演进」原则
「架构腐化」的常见场景:

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

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

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

7、微服务下线
原则 16:对于「废弃服务」,需要做好「下线」工作,包括服务下线、存储释放等。
清理无效代码、环境,减少维护成本。同时释放资源,节约成本。

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

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

你是否还在寻找稳定的海外服务器提供商?创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源,准确流量调度确保服务器高可用性,企业级服务器适合批量采购,新人活动首月15元起,快前往官网查看详情吧


网页题目:架构师进阶,微服务设计与治理的16条常用原则-创新互联
文章链接:http://myzitong.com/article/ggeed.html