架构设计之「入口统一」原则

今天的内容从一个真实的案例开始说起。

1. 故事开场

笔者所在的企业是一家面向灵活用工行业的科技服务提供商，主要提供佣金结算、实时发放、税务申报等业务。技术架构分为前端应用，后端业务应用以及共享服务中心。共享服务中心采用中台化思想，通过抽象、封装等方式，提炼出可广泛复用和集成的基础能力，其中结算服务就是其一，他统一负责与各个银行和第三方支付渠道进行交互，包括自动识别公对公来账、发起公对私转账请求、获取公对私转账的处理结果、查询电子回单等，为了保障系统提供稳定可靠的服务，结算服务提供了丰富的智能容错机制，包括阶梯式重试、挂起等待人工处理、幂等、泳道隔离等。

在实际运营过程中，经常因为银行和第三方支付系统反馈的错误码模糊不清，需要人工介入判断该笔交易实际上是处理成功还是失败，或者是发起重试，而大概率这些操作是直接针对结算服务的。为了提升日常运营工作的效率和安全性，产品规划了一个功能，在后台管理系统中增加对这些异常订单的处理功能。

那么问题来了，针对这些需要人工处理的订单，前端页面是应该直接请求结算服务的接口进行异常订单的获取、发起请求，还是说统一经过业务应用，再由业务应用进行条件判断和请求代理呢？因为在实际环境中，后端业务应用和结算服务是不同的团队维护的，结算服务同时支持了 3 个以上的上游业务服务。

单纯从技术的角度以及直觉来决策，似乎应该让前端应用直接与结算服务进行交互更为自然。因为确实大部分场景下处理的都是挂在结算服务中的订单。

但是事实上这样做真的合适吗？

超级思维

我们在思考一个具体问题的时候，很容易因为这是一个点状问题，四面八方似乎都是通畅的，各种方法似乎都可以解决问题，而且看起来也没啥明显的高低之分，从而陷入决策迷茫，无从下手。但是当我们把这个点状问题放到一个容器中，他自然就会被附加很多的约束，这个时候很多方向将不再顺畅，问题也就变得明朗了。而这个容器就是与之相关的“体系”，譬如案例中这个问题，他的体系包括产品功能结构、技术架构和团队结构。

从产品功能结构来看，运营人员使用的是前端应用，而对应的数据模型是业务应用的模型，里面会有客户、项目、批次、订单编号、用户姓名、身份证、银行卡、金额、各种税额、服务费等信息，这些也是运营人员理解的业务数据模型。而经过技术性的抽象，落到共享结算中心的数据模型中，剔除了客户、项目、批次、各种税额、服务费等强业务相关的信息，只留下更普适性的订单编号、用户姓名、身份证、银行卡、金额等信息。假设让前端应用直接与结算中心交互，就会存在一个典型问题，运营人员理解的数据模型，跟从结算服务提取的数据模型无法关联，从而无从下手。

这里衍生出一个问题，关于分层架构中的模型建设的意义和一般原则。

分层架构中各层的聚焦性和模型的独特性

在分层架构中，分层的目的是一个抽象的过程，每一层都有自己的关注点和数据模型，而这个模型是所属层通用的，而跨层不通用的。所以说，如果在分层架构中每一层的数据模型是一样的，那么可能需要思考一个问题，每一层的定位是不是不够清晰和聚焦？

当然，还有其他方面的约束，譬如技术架构层面的身份鉴权问题、应用架构领域的封装性问题，即后续结算服务变更逻辑，因为没有中间业务应用的中转，会直接影响前端的交互，还有如果后续订单处理问题出现在业务应用，目前的直连方案就更加无能为力了。

综合以上观点，会发现当把一个点状的问题放到他所处的体系内，事情就不会变得不着边际，而是有很多的约束，因为有了实际的约束，方案也就可以收敛了。

结论

所以，从架构设计出发，对外提供的接口能力，尽量保持入口统一，因为入口统一的背后，是业务模型的统一、技术方案的统一、架构体系的统一。

最后，善于运用超级思维，来解决具体问题。