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

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服务端中，我们需要实现远程接口，并对远程服务调用进行内部的转发，转发的逻辑也很简单，