打造企业级应用架构：统一请求入口与多样化基础组件的完美结合

1、前言

统一技术框架有利于进行技术沉淀、标注化技术规范、避免重复调研，从而节省人力成本。标注化将带来开发效率、产品质量、节省成本等方面的大幅提升。
统一技术框架只针对P0级别的项目有强制要求，其他级别的项目跟进实际情况决定是否引进新兴技术框架。
任何技术框架都有优缺点，技术框架选型避免一刀切的思想。一定要根据实际情况，选择合适的技术框架。
统一技术框架将是一个持续的过程，应持续更新；淘汰过时陈旧的技术框架，引入先进高效的技术框架。

2、项目类型

使用Java后端技术的目的就是构建业务应用，为用户提供在线或者离线服务。因此，一个业务应用需要哪些技术、依赖哪些基础设施共同决定了后端基础设施及项目的类型。常见项目类型有：

• Java 项目
• Web 项目
• SpringBoot 项目
• SpringCloud 项目
• Web Service 项目
• 插件项目

目前互联网项目基本上都使用maven 进行项目构建，可以根据项目类型，使用maven 构建对应类型的项目。一般情况下建议使用maven构建多模块springboot 项目。
C端Android/IOS产品推荐gradle进行项目构建。
项目打包统一使用 assembly打包插件。

3、统一请求入口-API网关

在移动APP的开发过程中，通常后端提供的接口需要以下功能的支持：

• 负载均衡
• API访问权限控制
• 用户鉴权

一般使用Nginx做负载均衡，每个业务应用里做API接口的访问权限控制和用户鉴权，更优化一点的方式则是把后两者做成公共类库供所有业务调用。
但从总体上来看，这三种特性都属于业务的公共需求，更可取的方式则是集成到一起作为一个服务或组件，既可以动态地修改权限控制和鉴权机制，也可以减少每个业务集成这些机制的成本。这种服务就是API网关，可以选择自己实现。也可以使用开源软件实现，如Kong和Netflix Zuul。

4、后端基础框架

业务系统按类型可分为：在线业务、内部业务，两种业务关注的点不同。
在线业务：面向互联网用户的应用、接口等，典型的特点就是：请求量大、高并发、对故障的容忍度低。
内部业务：主要面向公司内部用户的应用。比如，内部数据管理平台、广告投放平台等。相比在线业务应用，其特点: 数据保密性高、压力小、并发量小、允许故障的发生。 根据业务特点，可针对性封装公共组件、服务、适合业务的工具包等。根据实际情况确定封装类型及位置。

为了避免重复造轮子的情况发生，可以针对封装进行分级：

• 公司级别：公共组件、公共服务、公共框架
• 业务线级别：业务组件、业务服务、业务框架
• 项目级别：项目组件、项目服务

公司级别及业务线级别的封装一定要考虑好定位、范围、职责、健壮性及一定的扩展性。
公司级别的组件推荐有util和common组件。然后其他公共组件根据公司实际情况考虑，比如asm-client、sso-client、account、open-platform等。

4.1 MVC框架

统一开发流程、提高开发效率、屏蔽一些关键细节的Web/后端框架。典型的如SpringMVC、Jersey以及国人开发的JFinal以及阿里的WebX。目前Web 项目推荐使用 SpringMVC。

4.2 IOC框架

统一使用Spring

4.3 ORM框架

统一使用 MyBatis，备选Spring JdbcTemplate。
如果需要进行分库分表，公司应组织架构组统一封装dbsharding 分库分表组件。
或者使用开源的组件sharding-jdbc。当当网的sharding-jdbc从datasource层面解决了分库分表、读写分离的问题，对应用透明、零侵入。
为了在服务层面统一解决分库分表、读写分离、主备切换、缓存、故障恢复等问题，可以选用开源的Kingshard。

4.4 缓存框架

一般使用Spring的RedisTemplate即可，根据实际情况也可以对 Jedis做封装，支持客户端分布式方案、主从等。

4.5 性能检测框架

对于线上的Java应用，建议统一接入ZABBIX，可以提供系统、JVM等信息的监控。Jwebap 是一个可以使用的性能检测工具，有可能的话可以基于此项目做二次开发。

5、其他基础组件

5.1 HTTP

统一使用Spring RestTemplate。考虑到性能及特殊场景，可业务封装。

5.2 JSON

统一使用公司封装的 util 工具包，如果没有则推荐基于Gson封装JsonUtils。或者使用com.alibaba.fastjson2.JSON

import com.google.gson.Gson;
import com.google.gson.GsonBuilder;
import com.google.gson.JsonElement;
import java.lang.reflect.Type;

public final class JsonUtils {
    private static final Gson GSON = (new GsonBuilder()).setDateFormat("yyyy-MM-dd HH:mm:ss").disableHtmlEscaping().create();

    public static String toJson(Object obj) {
        return GSON.toJson(obj);
    }

    public static String toJson(Object obj, Type type) {
        return GSON.toJson(obj, type);
    }

    public static <T> T fromJson(String json, Class<T> clazz) {
        return GSON.fromJson(json, clazz);
    }

    public static <T> T fromJson(JsonElement jsonElement, Class<T> clazz) {
        return GSON.fromJson(jsonElement, clazz);
    }

    public static <T> T fromJson(String json, Type typeOfT) {
        return GSON.fromJson(json, typeOfT);
    }

    public static <T> T fromJson(JsonElement jsonElement, Type typeOfT) {
        return GSON.fromJson(jsonElement, typeOfT);
    }

    private JsonUtils() {
    }
}

5.3 FILE

统一使用 apache commons io 包

5.4 Bean Copy

统一使用Spring BeanUtils

5.5 内存缓存

根据实际情况，可使用公共组件Sample Cache，个性化缓存推荐使用 Guava Cache。

5.6 数据库连接池

统一使用 ali druid

5.7 日志

统一使用logback

5.8 RPC

RPC 协议统一使用 Google protobuf-rpc-pro。

5.9 文档

项目文档统一管理，没有硬性要求，公司保持统一就行。比如都用wiki、都用语雀、都用腾讯文档、钉钉文档、石墨文档，只要统一用一个平台就行，考虑文档的安全性，不要开放给外部访客查看就行。
API部分统一使用 swagger2.0。针对接口采用swagger注解方式进行描述，前端组统一开发Mock 系统。接口文档根据不同的项目单独维护自己的接口文档。
注意：API部分可能随时变化，建议采用链接方式到对应的项目文档中，以便后续更新。

5.10 搜索引擎

推荐使用Elasticsearch。

5.11 消息队列

统一使用RabbitMQ，备选 kafka，Redis。

5.12 文件存储

针对图片、音频、视频、文件，由前端架构组统一封装图床服务。服务端统一对接前端组图片服务。根据请求量级及存储空间需求，确认使用哪种方案。
图片等资源上传统一使用minio。业务量级要求较高可考虑使用 aws s3进行存储。 国内可以使用阿里云oos或腾讯的cos存储。
对于像请求日志，系统处理日志，需要长期存储的也优先考虑使用aws s3。也可根据实际情况跟大数据部门合作，存储到hbase 中。

5.13 统一认证中心

对接公司账号系统或者开放平台。
单点登录系统
对接公司统一SSO系统。
目前，比较成熟的、用的最多的单点登录系统应该是耶鲁大学开源的CAS, 可以基于 https://github.com/apereo/cas/tree/master/cas-server-webapp 来定制开发的。

5.14 统一配置中心

统一对接开源 Apollo。参考架构文档。

5.15 服务治理框架

统一对接 Nacos

5.16 统一调度中心

统一对接开源 XXJOB。

5.17 统一日志服务

如果公司基础运维部统一搭建ELK日志系统，则直接对接ELK。没有搭建的话可以考虑阿里云日志服务。

5.18 数据基础设施

根据公司业务应用根据类型大部分推荐使用mysql，内容类使用mongoDB。大数据使用HBase，实时流式计算使用 storm。
根据实际情况也可以考虑 newSQL。

PS：Oracle数据库除了收费没有缺点。MySQL免费，但需要你做好分库分表、性能瓶颈等问题。

5.19 故障监控

对于面向用户的线上服务，发生故障是一件很严重的事情。因此，做好线上服务的故障检测告警是一件非常重要的事情。可以将故障监控分为以下两个层面的监控：
系统监控：推荐使用ZABBIX，无特殊情况无需调整。
业务监控：封装业务监控系统，接入邮件、电话、微信等告警方式做好监控告警。