《微服务架构设计》之 正确打开方式

前言&背景

故事开始前先给大家讲一个段子,近些年随着软件系统架构的发展,我们经历了从单体应用到分布式系统,并且逐步向云原生迈进,而其中微服务架构是最具有代表性,但在微服务设计时又存在各式各样的问题,比如微服务拆分粒度过细,服务间调用深度过长,可能就要重新梳理业务考虑进行服务合并,这时就会有人问:“你们为什么把微服务拆了又合?”,你告诉他我们在“建中台”;然后随着业务的快速扩张,资源的利用上hold不住了,又要考虑对系统进行拆解,这时又会有人问:“你们为什么又把微服务合了又拆?”,你告诉他我们在“拆中台”;然后,当然还有然后,拆过之后发现有些服务拆的不合理,可能又要进行合并,此时有人问起:“What the hell are you doing ?”,你可以像一位老者一样回答他:“天下大势,分久必合,合久必分。周末七国分争,并入于秦。及秦灭之后,楚、汉分争,又并入于汉。汉高祖一统天下,后来光武中兴,遂分为三中台...

《微服务架构设计》之 正确打开方式

以上类似的场景在实际应用微服务设计时,很多人或许感同身受。如何对微服务进行合理的拆分和设计? 是否有相关的标准和规范可以参考,答案是有的,不过仅仅是方法论。从哲学的角度上讲并不存在普适的方案,不过根据经验可以总结和抽象一些方法作为指导,但是过度抽象之后又非常晦涩难懂,实施起来并不是一件容易的事。

微服务发展简史

首先我们先来回顾一下软件系统架构的发展历程:单体架构 --> 分布式/集群架构 --> 服务化架构(SOA面向服务) --> 微服务架构 --> 网格化/单元化架构

总的来说微服务架构囊括了之前架构的所有特点,分布式集群部署,面向服务的设计,而微服务更加关注的是服务拆分的粒度,即:一个服务要拆分到多大的维度合适。但随着系统业务量的增加,服务规模也越来越大,相应的也出现了一些新的问题,比如底层系统资源问题、服务间通信和治理问题、服务整体运维的问题,而SpringCloud、Dubbo等微服务框架只能解决软件开发层面的问题。早期的微服务,人们关注的重点都是软件开发层面,近几年随着容器化管理技术Docker、容器编排技术Kubernetes等,运维层面技术的成熟和推广,微服务体系由原来的注重开发,逐渐演变为设计、开发、运维一体化的DevOps管理模式。

《微服务架构设计》之 正确打开方式

通过服务架构的发展历程,我们可以看出:微服务实现了服务间的解耦,但同时也引发了很多非业务性问题。 比如:服务发现、服务限流、服务监控、服务权限控制、服务版本控制等。Spring Cloud等微服务框架,虽然为我们提供了,例如:解决服务发现问题的注册中心Eurek、解决限流问题的断路器Hystrix,以及解决服务调用问题的Ribbon、Fegin等技术,但是我们看看是它如何使用的?导入dependency依赖,将它们和我们的业务代码一起打包部署,也就是说Spring Cloud是一种”侵入式”解决方式,它虽然简化了我们处理非业务问题的难度,但是开发人员还是需要对这部分功能一定了解。

我们希望让业务开发人员,只关心业务代码开发,而不必将精力耗费在非业务代码的开发上,Service Mesh(服务网格)技术就是这种思想的体现,它可以帮助将非业务功能从代码中剥离处理,将整个服务间的网络通信抽离下沉到基础设施层面,例如:服务发现、负载均衡、版本控制、蓝绿部署等问题。

我们再回到微服务设计要解决的根本问题,即:微服务如何进行设计和拆分 ,下面梳理了一些在微服务架构设计时常用的原则和方法论:

  • AKF拆分原则
  • 业务拆分原则
  • 领域驱动设计
  • 分层架构设计

AKF拆分原则

我们先来聊一聊微服务设计的最基本原则:AKF扩展立方体(Scalability Cube)
《微服务架构设计》之 正确打开方式
AKF扩展立方体是《架构即未来》一书中提出的可扩展模型,这个立方体有三个轴线,每个轴线描述扩展性的一个维度。理论上按照这三个扩展模式,可以将一个单体系统进行无限的扩展。

  • X轴:指的是水平复制。很好理解,就是将单体系统多运行几个实例,做个集群加负载均衡的模式。为了更好的支撑这种水平伸缩能力,所以系统最好设计成前后端分离并且无状态服务。这种扩展能力成本最低,实施也最简单,适合发展初期,业务复杂度低,增加系统容量就可以解决大部分问题。
  • Y轴:指应用中职责的划分。这部分就是我们常说的微服务拆分模式,基于不同的业务进行拆分。这种属于业务上解耦的扩展能力,可以使团队更聚焦,同时解决代码复杂度的问题,但其中必然会牵扯到底层数据的隔离与传递,所以难度系数较大,适合业务复杂,数据量大,团队规模大的场景。
  • Z轴:指根据服务或者数据进行分区,比如按地域进行划分。这是实现成本最高的一种扩展方式,一般在超大型系统会有类似的需求,比如当一个互联网系统突然用户量激增,单一的集群模式可能无法承载,那就需要按照用户所在的地区进行服务和数据的分区。和传统意义上的分库本表或者逻辑上多租户不一样,需要对多个分区进行一定的物理隔离,类似近些年金融行业单元化架构,多数据中心的思路。适用于用户指数级的快速增长,并可以按照某种规则进行分区。

在关注AKF三个轴线拆分的同时,还需要思考3S原则,即:Safety(安全)、Scale(规模)、Speed(速度)

《微服务架构设计》之 正确打开方式

业务拆分原则

接下来从系统业务角度切入,谈谈微服务的拆分和设计原则。

明确微服务拆分,设计原则;以业务需求为中心、高度自治及持续演进为目标实现微服务化。

《微服务架构设计》之 正确打开方式

对于跨服务的调用首先是从业务角度考虑,做到高内聚,低耦合,通过拆分的原则尽量减少这种耦合的发生。

《微服务架构设计》之 正确打开方式

领域驱动设计

领域驱动设计(DDD:Domain-Driven Design),是一套更高级的对软件系统分析和设计的面向对象建模方法。和传统以数据驱动设计为中心的架构有很大区别,领域驱动设计更加关注的是领域模型,那么何为领域?直白些讲领域其实就是指一块业务范围而领域驱动设计就是将业务与业务之间的关系,以及业务内部的逻辑构建出来

《微服务架构设计》之 正确打开方式

在领域驱动设计中,首先要做的并且也是最重要的一步,就是达成共识,将团队中包括技术人员、领域专家、产品经理等对该领域相关的业务知识达成共识,大家能够简单清晰准确的描述该领域的业务含义和规则,这就是统一语言(Ubiquitous Language)。通过达成这种共识来解决在一些中大型软件系统中的业务复杂度,是一套行之有效方式。

《微服务架构设计》之 正确打开方式

有了通用语言后,如何将业务模型进行组织和落地,这部分就是模型驱动设计(Model-Driven Design)阶段。DDD将这个模型设计过程分为了两个阶段:

  • 战略设计(Strategic design)
  • 战术设计(Tactical design)

所谓战略设计,也称为高层设计,指将系统拆成不同的领域,换句话说:哪些是核心域(核心竞争力),哪些是通用域(非核心共用的,可外采的),哪些是支撑域(非核心特有的,可外包的)。

所谓战术设计,指如何具体的组织不同的业务模型,换句话说:这些模型是什么角色(实体、值对象)?这些模型之间是什么关系(聚合、聚合根)?这些模型如何协作和演变(领域事件、领域服务、工厂、仓库、应用服务)?

《微服务架构设计》之 正确打开方式

然后对领域模型进行界限上下文划分,并标识出之间的依赖关系,形成类似上图一样的领域模型设计,最终再将界限上下文或其中的领域模型映射成微服务。

领域驱动设计这种面向业务的设计方法,与今天的敏捷式开发和微服务架构体系具备天然的契合度。

分层架构设计

最后基于以上的设计原则和方法,我们再来看看分层架构设计,对于分层设计我想大家应该都会不陌生,但在微服务架构中应该如何进行分层,可以参考如下中台建设场景:

聚合域:聚合中台业务完成业务流程
业务域:提供中台业务能力接口
通用域:提供数据的原子操作接口

《微服务架构设计》之 正确打开方式

分层架构的好处是可以让服务之间关系更加清晰,同层之间尽量不要相互调用,也要避免跨层级调用,整个调用链的深度也要控制在一定范围。

结束语

没有最好的设计模式和架构方案,只有对系统持续的优化和演进,需要找到系统性能的瓶颈点,找到架构设计中腐化的地方,找到确实可行的方法,然后,不断优化和提升系统的质量,架构的魅力正在于此。

“你写的每一行代码都是你的名片,你fix掉的每一个bug都算数,这不是编程的技术,这是编程的艺术。” -- 致敬《飞驰人生》

上一篇:HBase Thrift客户端Java API实践


下一篇:性能测试的基础概念原理