系统架构合理性的思考-京东云开发者社区

最近牵头在梳理部门的系统架构合理性，开始工作之前，我首先想到的是如何定义架构合理性？

从研发的角度来看如果系统上下文清晰、应用架构设计简单、应用拆分合理应该称之为架构合理。

基于以上的定义可以从以下三个方面来梳理评估：

1、系统的上下文清晰：明确的知道和周围系统的调用关系，数据同步机制；

2、应用架构设计简单：架构分层合理，功能定位清晰，不会出现功能边界之外事情；

3、应用拆分合理：系统内的应用粒度在一个合理的范围内；应用间调用链路不应过长。

### 系统的上下文清晰

系统上下文图一词最早是从Simon Brown的C4模型中借用而来的，该模型”通过在不同的抽象层次重新定义方框和虚线来抽象表达架构的含义“。

C4模型把系统分为四层，每层都代表着不同的视图架构，关注点不同。第一层，讲的系统上下文，系统高层次的抽象。

如下图显示个人银行账号在浏览账户过程中发生不同的系统之间交互。 如果把Internet Banking Sysytem 当成我们的目标系统，那么E-mail System、MarinFrame Banking Sytem 就是它的伴生系统，也可以称为外部系统，它给Internet Banking Sysytem 提供系统价值，属于系统外，是黑盒。

![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-08-14-21-31gIAcUOsksddsMRo.png)

系统上下文明确了目标系统和外部系统的关系，它和外部系统一起给目标用户提供价值。绘制系统上下文的时候，需要注意目标系统和外部系统之间的依赖方向。北向依赖意味着外部系统调用目标系统的服务，需要考虑目标系统定义了什么样的服务契约；南向依赖意味着目标系统调用了外部系统的的服务，需要了解外部系统的接口、调用方式，通信机制，甚至当外部系统出现故障时，目标系统该如何处理。

除了参考以上的画法，也可以用业务序列图表示。它脱胎与UML的序列图。序列图可以从左侧的角色开始，体现消息传递的次序。这隐含这一种驱动力：我们从左侧的参与对象开始，寻找与之协作的执行步骤，然后层层传进地推导出整个完整的协作流程。

企业序列图，代表了企业级系统的抽象，目标系统和外部系统之间的协作关系，参与的系统是一个完整的整体，所以不需要也不应该参与系统的内部实现的细节，消息的方向更多的代表系统的责任。业务序列图如下所示：

![](https://s3.cn-north-1.jdcloud-oss.com/shendengbucket1/2023-08-14-21-32fIMK69txOVSiPTB.png)

### 应用架构设计简单

应用本身是有架构分层的，Martin Fowler 在《企业应用架构模式》 提出合理的系统分层应该包括表现层，领域逻辑层，数据源层。 表现层主要提供服务，处理用户请求。领域层是处理逻辑，是系统的核心。数据源层与数据层、消息系统，与其他软件包通信。

后续发展的领域驱动架构设计，演变成四层，在表现层下加入了应用层，同时把数据源层改为基础设施层，突破了数据库管理系统的限制。

基于以上的系统分层，无论你是采用的三层架构还是四层架构，应用代表着功能边界，提供那些核心的能力，能做那些事情，那些事情不能做。

一个好的实践经验是参考领域驱动设计的业务域的方法论，梳理好系统的一二三级域，最多不超过四级，做好各级域的定义。好的域的定义代表着系统能力的边界，让你明白那些事情能做，那些事情不能做。

基于以上梳理好的系统业务域的定义和能力边界，我们在梳理的时候通常会两类系统，第一类是现有存量的系统且需求迭代相对频繁的系统，这类系统关键是要梳理出有哪些核心的能力，是否在上述系统的域的定义范围内的，是否其他系统有类似的能力，如果有的话，需要考虑合并。另外还需要考虑核心能力公开化、文档化，至少让部门内知道，有地可查，避免系统的重复造轮子。

遇到第二类系统是存量系统且没有需求迭代，业务上基本没有调用量的。这类系统需要和业务沟通是否有下线计划，是否有类似的系统可以替代，给业务决策提供技术参考。

### 应用拆分合理

需求开发中，一个项目或者需求的实现可能需要多个目标系统协同来实现，这涉及到目标系统的拆分的粒度，系统拆分成应用的粒度没有统一标准，但是要在相对合理范围内，可以参考的因素包括业务规划，系统调用量级，基于业务规划的架构设计，部门内的人数及分工。过多过少都是不好的。

如果一个新业务短期内看不到大的发展，在初步规划应用的时候，可以先粗粒度拆分，部门内人数平均不能应该超过2-3个应用，再多必然面临着一个需求实现的时候不同系统的切换成本。如果后续业务发展起来，部门内人数增多，因为分工更精细，可以考虑更细粒度的拆分，系统拆分必然会带来另一个问题，系统之间该如何的协同以及系统的调用链路的长度。

基于以上讲的系统分层的概念，部门内系统可以分为两类，一类系统是业务网关，一类是通用的业务能力。业务网关面向用户，用来协同应用的活动，不包含业务逻辑，不保留业务对象的状态，相当于领域驱动设计应用层+表现层，有人称作它为业务SOA，或者BFF层。

通用业务能力相当于领域逻辑层+基础设施层，作为软件的核心所在，保留了业务对象的状态，对业务对象的持久化被委托给基础设施层，基础设施层作为其他层的支撑层，实现了和其他系统的通信，实现业务对象的持久化。

在以上两类系统中，业务网关是依赖通用业务能力层，业务网关是北向依赖，通用业务能力层是南向依赖。 在一个功能的实现不建议链路长度不超过2。同时也要注意到系统之间相互依赖的情况，要重视，此点是系统稳定性的风险点。

### 成本量化：

基于以上三方面分析，梳理出的交付物:1、系统的上下文依赖；2、 系统的业务域定义及能力规划地图。3、应用调用链路的长度及相互的依赖关系；4、应用拆分粒度合理性的评估；5、系统中能力的下沉或者合并；6、业务量少的系统列表。

其中1-4，可以看作系统的行动指南或者原则，5-6是下一步的行动，更简单的说是我们常做的系统的关停并转。在业务部门系统关停并转还需要考虑到成本问题，做好成本的量化。

首先需要评估关停并转的付出的成本，其次要评估系统日常维护1-3年的成本包括人力成本和机器资源的成本，前者和后者的三年累计值相减，如果大于零，系统建议暂时不动，如果少于零，可以考虑关停并转的计划。

以上是我从研发角度系统架构合理性的思考。

架构合理性如果从业务角度来评估，可能就变成以下三个方面：一是能解决当下业务需求和问题。2、高效完成业务需求: 能以优雅且可复用的方式解决当下所有业务问题。3、前瞻性设计: 能在未来一段时间都能以第2种方式满足业务，从而不会每次当业务进行演变时，导致架构翻天覆地的变化。

视角的不同必然代表着大家对同一件事情的看法不同。