互联网后端基础设施规划.docx

互联网后端基础设施规划对于一个互联网企业，后端服务是必不可少的一个组成部分。抛开业务应用来说，往下的基础服务设施做到哪些才能够保证业务的稳定可靠、易维护、高可用呢？纵观整个互联网技术体系再结合公司的目前状况，个人认为必不可少或者非常关键的后端基础技术/设施如下图所示：Api网关业务应用和后端基础框架缓存、数据库、搜索引擎、消息队列文件存储统一认证中心单点登录系统统一配置中心服务治理框架统一调度中心统一日志服务数据基础设施故障监控这里的后端基础设施主要指的是应用在线上稳定运行需要依赖的关键组件/服务等。开发或者搭建好以上的后端基础设施，一般情况下是能够支撑很长一段时间内的业务的。此外，对于一个完整的架构来说，还有很多应用感知不到的系统基础服务，如负载均衡、自动化部署、系统安全等，并没有包含在本文的描述范围内。Api网关在移动app的开发过程中，通常后端提供的接口需要以下功能的支持：负载均衡api访问权限控制用户鉴权一般的做法，使用nginx做负载均衡，然后在每个业务应用里做api接口的访问权限控制和用户鉴权，更优化一点的方式则是把后两者做成公共类库供所有业务调用。但从总体上来看，这三种特性都属于业务的公共需求，更可取的方式则是集成到一起作为一个服务，既可以动态地修改权限控制和鉴权机制，也可以减少每个业务集成这些机制的成本。这种服务就是Api网关(/pzxwhc/article/details，可以选择自己实现，也可以使用开源软件实现，如Kong。如下图所示：但是以上方案的一个问题是由于所有api请求都要经过网关，它很容易成为系统的性能瓶颈。因此，可以采取的方案是：去掉api网关，让业务应用直接对接统一认证中心，在基础框架层面保证每个api调用都需要先通过统一认证中心的认证，这里可以采取缓存认证结果的方式避免对统一认证中心产生过大的请求压力。业务应用和后端基础框架业务应用分为：在线业务应用和内部业务应用。在线业务应用：直接面向互联网用户的应用、接口等，典型的特点就是：请求量大、高并发、高可用、对故障的容忍度低。内部业务应用：这个是面向公司内部的应用。比如，内部数据管理平台、广告投放平台等。相比起在线业务应用，其特点: 数据保密性高、压力小、并发量小、允许故障的发生。业务应用基于后端的基础框架开发，针对Java后端来说，应该有的几个框架如下：MVC框架：从十年前流行的Struts1、2到现在最为推崇的SpringMVC、Jersey以及国人开发的JFinal、阿里的WebX等等，这些框架尤其是后面流行的这些都是各有千秋的。选型的主要因素是看你的团队是否有一个对某框架能够做二次开发、定制的人在。很多时候，针对这些通用的框架，你是需要做一些特定的开发才能满足特定的需求的。比如，很多团队传递参数使用的都是UnderScore的命名法(下划线连接单词)，但是Java中确是使用LowCamel命名的。对于SpringMVC，可以通过注解的alias来指定，但这样需要对每一个参数都要指定alias有点效率太低，此外ModelAttribute也不支持别名，更好的方式是在框架层面统一对参数做Camel命名的转换达到目的。IOC框架：ioc带来的好处无须多言。目前Java中最为流行的Spring自诞生就天然支持IOC。ORM框架：MyBatis是目前最为流行的orm框架。此外，Spring ORM中提供的JdbcTemplate也很不错。当然，对于分库分表、主从分离这些需求，一般就需要实现自己的ORM框架来支持了，像阿里的tddl。此外，为了在服务层面统一解决分库分表、主从分离、主备切换、缓存、故障恢复等问题，很多公司都是有自己的数据库中间件的，比如阿里的Cobar、360的Atlas、网易的DDB，还有官方提供的MySQL Proxy以及开源的MyCat、kingshard和收费的oneproxy。目前，线上有一定规模使用的应该是kingshard，当然如果不缺钱也可以上oneproxy。缓存框架：缓存框架主要指的是对redis、memcached这些缓存服务器的操作统一封装，一般使用Spring的RedisTemplate即可，也可以使用jedis做自己的封装，支持客户端分布式方案、主从等。JavaEE应用性能检测框架：对于线上的JavaEE应用，需要有一个统一的框架集成到每一个业务中检测每一个请求、方法调用、jdbc连接、redis连接等的耗时、状态等。jwebap是一个可以使用的性能检测工具，但由于其已经很多年没有更新，有可能的话建议基于此项目做二次开发。一般来说，以上几个框架即可以完成一个后端应用的雏形。对于这些框架来说，最为关键的是根据团队技术构成选择最合适的，有能力开发自己的框架则更好。此外，这里需要提供一个后端应