在阿里架构师眼中构建一个较为通用的业务技术架构就是如此简单

构建通用业务技术架构：阿里架构师的经验分享

最新推荐文章于 2025-09-30 10:39:34 发布

原创

最新推荐文章于 2025-09-30 10:39:34 发布 · 2.2k 阅读

8 ·

CC 4.0 BY-SA版权

文章标签：

#JAVA #分布式 #架构

本文介绍了阿里架构师眼中构建通用业务技术架构的方法，从网关层、业务层到基础层，详细阐述了各层的实现与职责。网关层负责协议处理和业务逻辑收敛，业务层包括服务、流程和组件，基础层涉及接口定义和技术组件。通过这样的架构设计，可以提高系统的适应性和可维护性。

1，通用架构概述

创业之初，我们往往会为了快速迭代出产品，而选择最简单的技术架构，比如LAMP架构，SSH三层架构。这些架构可以适应初期业务的快速发展，但是，随着业务变得越来越复杂，我们会发现这些架构越来越难支撑业务的发展，出现在一个类中写好几千行代码，一个方法中到处都是if if else语句，如果中间遇到主程序猿离职，后面介入的程序猿几乎无法理解这些代码，到最后，产品越来越难迭代，只能推翻重做。如果我们在创业初始就以一种适应性较强的架构去写代码，后面就会少走很多弯路。下面的文章是我自己总结出来的一套架构，经过实践，适应性还算不错。

2，通用架构实现

总的来说我的通用架构还是以三层架构为基础进行演变的，在经典的三层架构中，最上层的是控制器，中间是服务，下层是DAO。在我的架构中，最上层是网关层，控制器只是网关的一种，中间是业务层，服务只是业务层的入口，最下层是基础层，DAO只是基础层中的数据存储组件。

2.1，网关层

网关层本质上是对不同的网络协议的请求进行处理，比如HTTP协议，TCP协议，当然，也可以对其他协议进行处理具体见下图：

2.1.1，HTTP请求

一般来自PC端和APP端的请求都是基于HTTP协议的，对于处理HTTP请求的方案，业内已经非常成熟了。首先，tomcat容器本身已经把HTTP请求处理的复杂性封装掉了，其次，spring mvc对请求处理提供了RESTful的风格的编码方式，大大降低了开发的复杂度。我们要做的就是对控制器按照业务领域划分，比如按照订单，会员去划分大的领域，里面的各种方法就是这个领域内的操作。这里的控制器就是统一网关处理层，对于每个控制器的方法只做三件事，第一，将请求参数解析出来并组装成内部参数，第二调用下层服务执行业务逻辑，第三组装返回结果，对于异常情况，需要记录异常堆栈日志并转换错误码，堆栈信息不要暴露到调用方。

2.1.2，TCP请求

对于处理TCP请求的方案，业内也已经很成熟了，比如Netty。但是，TCP请求毕竟太底层，我们往往会基于TCP协议去开发自己的协议。另外，很多分布式框架都是基于TCP协议的，比如RPC框架Dubbo，消息框架RocketMQ等等。从单机系统到分布式系统，无非就是网关层多了处理TCP请求的逻辑，理论上底层的业务是无需感知自己到底是出于单机环境还是分布式环境，网关层的作用就是要屏蔽这种不同外部调用源的细节。在Dubbo服务端中，我们需要实现