1, General Architecture Overview
Start at the beginning, we tend to rapidly iterate the product, and select the most simple technical architecture, such as the LAMP architecture, SSH three-tier architecture. The architecture can adapt to the rapid development of business early, but as the business becomes more complex, we will find it increasingly difficult to support the development of these infrastructure business, there has written thousands of lines of code in a class, a method in full if else statement, if the middle of the main program ape encounters leave behind intervention program ape is almost impossible to understand the code, in the end, more and more difficult product iteration, only the overthrow of the redo. If we are in an initial start on the adaptability of the framework to write code behind it will take a lot less detours. The following article is a summary of my own out of a framework, through practice, adaptability pretty good.
2, common architecture to achieve
Overall my common architecture or three-tier architecture as the basis for the evolution of the classic three-tier architecture, the uppermost layer is controller, the middle is the service, the lower is the dao. In my architecture, the gateway is the uppermost layer, only a Gateway Controller, the intermediate layer is a service, service entry except the service layer, the lowermost layer is the base layer, the base layer except DAO data storage components.
2.1, the gateway layer
Is a processing request for different network protocols on the nature of the gateway layer protocol such as HTTP, TCP protocol, of course, other protocols may be processed. Specifically shown below:
2.1.1, HTTP request
General requests from PC end and APP are based on the HTTP protocol for handling HTTP requests program, the industry is already very mature. First, the container itself Tomcat HTTP request processing complexity of the package out, secondly, spring mvc request process provides for RESTful encoding greatly reduces the complexity of development. All we do is for the controller in accordance with the division of business areas, such as in accordance with the order, membership to divide large areas, a variety of methods which is operating in this field. Gateway controller here is uniform treated layer, each controller for only three things a method, first, the request is parsed and assembled into parameter internal parameters, the second call to the underlying business logic of the service execution, returns the result of the third assembly, for unusual circumstances, need to record and convert the exception stack logs the error code, do not expose the stack information to the caller.
2.1.2, TCP request
For TCP request processing program, the industry has also been very mature, such as Netty. However, the underlying TCP requests after all, too, we tend to develop their own protocol based on the TCP protocol. In addition, many distributed framework is based on the TCP protocol, such as RPC framework Dubbo, messaging framework RocketMQ and so on. From standalone systems to distributed systems, multi-layer gateway is nothing more than the logical processing TCP requests, in theory, the underlying business is no need to perceive themselves in the end for a stand-alone environment or a distributed environment, the role of gateway layer is to shield this difference details of the source of external calls. In Dubbo server, we need to implement a remote interface and remote service call forwarding internal forwarding logic is very simple, first of all is to parse the parameters and assembling the internal parameters, and then call the business layer interface performs business logic, and final assembly return result, for exception handling need to do out here, to prevent abnormal exposure to external applications.
2.1.3 Summary
Gateway protocol layer processed essentially simultaneously converge to the business logic layer gateway, not exposed to the outside when the internal business logic reconstructed external caller does not need to perceive these changes, increases when the source external calls , internal service logic does not need to change this perception, so that the internal and external caller business logic decoupling.
2.2, the business layer
Business layer is a system, whether it is a local business systems, business layer single system or distributed systems group are carrying business processes and rules. Service from outside to inside layer comprising three layers: a service business, the business process is the second layer, the third layer is a business component. FIG follows:
2.2.1 Business Services
Business is business services layer of uniform external facade, which consists of three areas: the business interface, the Senate and the parameters.
a) Service Interface
一个业务接口代表一个领域的业务服务，比如订单域的业务服务就由接口OrderService表示，会员域的业务服务就由接口MemberService表示。接口可以按照执行性质分为读接口和写接口，比如OrderReadService和OrderWriteService。读写分离的好处是可以对集群进行读写分组，从而管理流量，当然，单机系统读写分离意义不是太大。领域内的操作则以业务接口中的方法的形式体现，比如订单域有下单createOrder，取消订单cancelOrder等等操作。对于这些操作，尽量设计出有业务含义的方法，而不是增删改查，当然，对于一些简单的业务，也只能增删改查。
b)入参
接下来，是入参的设计。入参对于读方法，比较简单，不做讨论。对于写方法，我们将入参设计成有层次的数据模型。首先需要设计出公共的数据模型，比如订单数据模型，商家数据模型，商品数据模型等，然后将这些数据模型和一些特定业务下的个性数据结合，组成Request对象，这个request对象按照不同业务操作不同而不同，对应的返回结果就是response，它也是随着不同业务返回的参数不同。
举个例子，拿下餐饮订单来说，首先，我们应该识别出这些业务流程中一些比较基础的数据模型，比如餐饮领域的菜品、桌位等，这些模型之所以说是基础模型，是因为，不管下什么餐饮订单，菜品和桌位肯定是逃不了的，它们是可以被复用的！因此，我们分别为这些基础模型设计相对于的DO（Domian Object）:DishDO（菜品）、BoardDO（桌位）等等，接下来，我们为下餐饮订单设计一个请求对象DishOrderCreateRequest其中DishOrderCreateRequest内部包含了DishDO和BoardDO，另外会包含一些特定的属性，比如人数啊，折扣啊等等，这样一来就能做到通用和灵活兼顾，DishOrderCreateRequest代表的个性化的灵活的业务入参，而DishDO和BoardDO等则代表了不易变化的基础模型。
c) 出参
最后，是出参的设计。对于写方法，一般出参比较简单。对于读方法，出参往往是一个结构与层次比较复杂的组合对象。比如查询一个订单，这个订单有订单基本信息，还有商品信息，收货人地址信息等。在设计出参的时候，结构上要设计成组合对象，但是真正查询的时候，通过查询选择器，去查询不同的组合对象。比如查询选择器设置商品查询为true，地址查询为false，那么这次查询出的订单就只包含商品，而不包含地址。
2.2.2、业务流程
业务流程其实就是对业务规则的解释，只是这种解释使用代码去实现的，我们要做的其实就是准确翻译这些业务规则，并维护好这些业务规则。
业务流程中可以大致分为三种动作节点，1、组装参数节点 2、规则判断节点 3、执行动作节点，其中每个动作节点都是一些业务代码的片段。举个例子，下餐饮订单，我们第一步就是将上层传入的参数组装出一个基础的DishOrderDO（组装参数节点），然后按照特定的规则去填充这个DishOrderDO（规则判断节点），然后就是调用DAO去创建DishOrderDO（执行动作节点）。
业务流程是最容易变化的地方，要想维护好业务流程并不容易，总的思想是将大的业务流程拆分成小的业务流程，抽出每个业务流程中共有的代码片段，变成可维护的业务组件。
2.2.2、业务组件
a) 基础组件
业务组件其实是将一些内聚的可复用的代码片段进行封装。和业务流程中的三种业务节点相对应，业务组件也分为三种：组装参数组件 、规则判断组件 、动作执行业务组件。业务组件的抽象往往是对业务有了深刻理解之后才进行的，盲目地进行业务组件的抽象，往往到头来白忙活。
b) 能力
对业务组件进行进一步抽象，可以得到能力。业务能力是具有一定复用性的组件的组合，比如发短信能力=组装短信参数组件+发短信组件。对于发短信能力，可以被不同的业务流程复用，比如订单下单成功发短信，支付成功发短信，逻辑都是相似的，只有内容不同。能力是一种粒度比较大的组件，粒度越大，往往复用性就越小，对能力的抽取，也是基于对特定业务深刻的理解，没有一劳永逸的银弹。
c)更高纬度的抽象
经过本人的实践，对于互联网这样的需求变化极快的场景，更高纬度的组件抽象往往性价比很低，不建议大家去做。
2.3、基础层
基础层包含两个部分，第一是接口定义，第二是技术组件。
2.3.1、接口定义
接口定义是按照不同的技术框架，同时结合业务需要，设计出合理的接口，对于业务组件来说，它们只会感知技术接口，而不会去感知技术实现，我们也不应该将具体的技术细节向上暴露，这也就是所谓的面向接口编程。技术接口往往是业务与技术之间的桥梁，接口本身是含有业务含义的，最常见的就是DAO接口，我们设计DAO接口的时候，不会设计成insert、update、query这样业务无关的接口，而是设计成insertUser，updateUserById等等和业务相关的接口，同样的道理，设计缓存接口的时候，也不能设计成put、get这样的接口，而应该设计成cacheUser，deprecateUser这样的接口。
2.3.2、技术组件
单机系统的技术组件一般来说分两种，一种是通用的技术组件，比如：数据存储、缓存、消息和调度任务、事务、锁。一种是基础设施，比如spring容器，tomcat容器。下面稍微谈谈通用技术组件。
数据存储：数据存储包括关系型数据库、非关系型数据库以及文件存储系统。关系型数据库，比如MySQL，适合存放绝大部分业务数据。非关系型数据库，比如hbase，可以存放历史日志，也可以对历史的MySQL数据进行归档。文件存储系统，一般都是基于Linux文件系统，比如图片、html文件等等，也有基于HDFS的，用于大数据分析。
Cache: Cache divided by response time, can be divided into nanosecond cache, cache milliseconds and hundreds of milliseconds level cache. Nanosecond cache is generally based on the local memory cache, such as encache, millisecond-level cache is generally centralized cache memory, such as memcache, due to access remote call, so the response time will be extended to a few milliseconds, a hundred milliseconds general cache is a centralized be persistent caching, such as Redis, remote access, and the presence of breakdown due to cache read persistent record, its response time will be longer, to tens or even hundreds of milliseconds. Stand-alone systems generally use a local cache memory is enough, when the cache is the breakdown of direct access to the database.
Messaging and scheduling tasks: information and scheduling tasks are essentially an asynchronous means of, except that the asynchronous message can not control time, and you can schedule tasks. Generally, the message is sent, the system listens for messages will receive the message immediately, thus immediately trigger the execution of business logic, and scheduled tasks will be scheduled in accordance with the rules, one or more times to perform the business logic. Stand-alone system messages and schedule tasks used less, do log monitoring may be useful when the message carrying data report statistics might be used when scheduling tasks.
Services: Services are based on the nature of the database to achieve, the transaction is dependent on a stand-alone system transaction database, we can use transaction templates spring-tx of transaction operations, business logic development, we must grasp the size of the transaction, it is recommended to business more closely bunch of database operations in a single transaction, are not free to open a transaction for each method.
Lock: stand-alone system mainly uses two kinds of locks: optimistic and pessimistic locking. Optimistic locking in the business relies on the table plus the version of the database field is achieved, every update to judge whether the version change, if the change you need to try again, this lock granularity is relatively small. Pessimistic locking is based on the JDK Lock interface for a business process for locking and releasing operation of the lock, the lock is relatively coarse particle size.
3, summary
These are groping after I passed out of practice for a long time business technology architecture, since that is fairly common, and can support variable business to some extent. Of course, this architecture is certainly not a silver bullet, can not solve all business scenarios, so eventually we need to be around to learn specific scene.