创业之初，我们往往会为了快速迭代出产品，而选择最简单的技术架构，比如LAMP架构，SSH三层架构。这些架构可以适应初期业务的快速发展，但是，随着业务变得越来越复杂，我们会发现这些架构越来越难支撑业务的发展，出现在一个类中写好几千行代码，一个方法中到处都是if else语句，如果中间遇到主程序猿离职，后面介入的程序猿几乎无法理解这些代码，到***，产品越来越难迭代，只能推翻重做。如果我们在创业初始就以一种适应性较强的架构去写代码，后面就会少走很多弯路。下面的文章是我自己总结出来的一套架构，经过实践，适应性还算不错。
2、通用架构实现
总的来说我的通用架构还是以三层架构为基础进行演变的，在经典的三层架构中，最上层的是controller，中间是service，下层是dao。在我的架构中，最上层是网关层，controller只是网关的一种，中间是业务层，service只是业务层的入口，最下层是基础层，dao只是基础层中的数据存储组件。
2.1、网关层
网关层本质上是对不同的网络协议的请求进行处理，比如HTTP协议，TCP协议，当然，也可以对其他协议进行处理。具体见下图：
2.1.1、HTTP请求
一般来自PC端和APP端的请求都是基于HTTP协议的，对于处理HTTP请求的方案，业内已经非常成熟了。首先，tomcat容器本身已经把HTTP请求处理的复杂性封装掉了，其次，spring mvc对请求处理提供了RESTful风格的编码方式，大大降低了开发的复杂度。我们要做的就是对controller按照业务领域划分，比如按照订单、会员去划分大的领域，里面的各种方法就是这个领域内的操作。这里的controller就是统一网关处理层，对于每个controller的方法只做三件事，***，将请求参数解析出来并组装成内部参数，第二调用下层服务执行业务逻辑，第三组装返回结果，对于异常情况，需要记录异常堆栈日志并转换错误码，堆栈信息不要暴露到调用方。
2.1.2、TCP请求
对于处理TCP请求的方案，业内也已经很成熟了，比如Netty。但是，TCP请求毕竟太底层，我们往往会基于TCP协议去开发自己的协议。另外，很多分布式框架都是基于TCP协议的，比如RPC框架Dubbo，消息框架RocketMQ等等。从单机系统到分布式系统，无非就是网关层多了处理TCP请求的逻辑，理论上底层的业务是无需感知自己到底是出于单机环境还是分布式环境，网关层的作用就是要屏蔽这种不同外部调用源的细节。在Dubbo服务端中，我们需要实现远程接口，并对远程服务调用进行内部的转发，转发的逻辑也很简单，首先是解析参数并组装内部参数，然后调用业务层的接口执行业务逻辑，***组装返回结果，对于异常处理也需要在这里做掉，防止异常暴露给外部应用。
