中台架构思考——基于微服务架构和六边形架构
1. 引言
微服务架构可以说是目前人气最高并且最受欢迎的软件架构模式，它完全迎合现在的软件开发模式，在保证高并发、高可用的前提下，尽量降低复杂软件的开发成本和部署成本。
然而在海量的微服务工程中避免不了的就是重复的造轮子，或者两个模块间的很小的区别也会驱使开发者重新开发一个微服务而不是优化已有的微服务（开闭原则），这直接造成了服务器上运行了大量的功能相似的代码，且我们需要维护它们所有。
随着中台架构思想的兴起，微服务单元的标准化和可重用性也越来越被重视，本着通用基础服务下，沉定制业务服务上浮的原则，硬生生把海量微服务一刀切为两类，但是大部分中台迎合业务的最终结果就是中台里会添加大量适配业务的模块，导致中台失去了通用性，最终导致中台越来越臃肿，变为糅合了各个业务方逻辑的怪兽。
![]()
2. 六边形架构和GraphAPI
![]()
六边形架构又称为端口-适配器架构，从内到外分为：内核层、适配层、接入层。六边形架构和中台架构做对应关系的话，六边形架构的内核层可以比作中台本身，六边形架构的接入层可以认为是中台架构中的上层业务单元，六边形架构的精髓之适配层在中台架构中并没有体现。
GraphAPI是Facebook开源的一种接口查询语言，用github的原话是：
我们为API v4选择GraphQL，是因为它为我们的集成商提供了显著的灵活性。相比于REST API v3，它最强大的优势在于，你能够精确的定义所需要的数据，并且毫无冗余。通过GraphQL，你只需要一次请求就能取到通过多个REST请求才能获得的数据。
说白了意思就是前端请求后端API时，传入参数指定请求哪个数据模型的哪个字段，后端根据这个参数精确推送数据，从而达到更少的request，更准确的数据推送。说到底也是一种适配思想，用静态的API为Client动态的裁剪并推送数据。
3. 中台思想、六边形架构和GraphAPI
从上面的描述中感觉，中台服务其实是一个很尴尬的东西，它既不能最终为程序员和产品开发节省什么，也不能为老板实际获利，或者这句话有点偏激，不过中台确实增加了系统的复杂性，并且有最终落地质量的不确定性（勿喷(^_^)）。
计算机界有一句名言：“任何软件工程遇到的问题都可以通过增加一个中间层来解决”。能不能在中台服务和业务单元之间加一层，像六边形架构一样。
![]()
适配层适配业务单元和中台之间的不对等，并且可以做一些权限方面的校验和过滤，中台中的通用服务只需要提供最基本的CRUD功能即可，并且也不需要做大量的权限、业务定制等逻辑，保持中台服务的单纯性，所有的这些差异交给适配服务来搞定。为了快速适配业务层的多变性，适配层的开放API接入GraphAPI能力，做到根据业务层传过来的参数动态组装元数据并返回。
![]()
4. 小结
加入适配层有好处也有坏处，坏处是增加系统整体复杂性且适配层可能会成为系统瓶颈，好处也比较明显：
- 保护中台通用能力的简单性和专业性。
- 业务层的易变性和不同业务的差异性不会直接影响到中台通用能力。
- 现有业务不会拖死中台的演进和进化的步伐。
- 当有新业务单元接入时不需要迁就其他业务单元的历史包袱，快速接入。
