1.0后端开发者对系统关注的点

• 可用率：能够正常提供服务的时间占线上总运行时间的百分比
• 稳定性：服务在异常和危险的情况下保持稳定的能力
• 容错性：在服务出现错误和异常的时候，能够继续提供一定服务的能力，主要强调的是容许误差和故障的能力
• 扩展性：主要指服务的动态扩展能力，即通过扩展（而非修改）现有系统的能力来满足需求的能力
• 可维护性：指的是修正服务错误、修改服务功能的能力
• 安全性： 报账系统以及用户数据安全的能力，包括保障系统不被非法入侵、用户数据不被泄露等等。

后端基础设施

后端基础设施图示

请求统一入口--API网关

后端接口需要提供的支持

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

缺点

所有的API都经过网关，会造成系统的性能瓶颈。解决方案是通过去掉API网关，转由调用统一认证中心，通过缓存的方式表面对统一认证中心造成过大的请求压力

1.1.2业务应用和后端基础框架

业务应用可分为在线业务应用和内部业务应用

• 在线业务应用：直接面向互联网用户的应用、接口等，典型的特点就是高并发和对故障的容忍度低
• 内部业务应用：主要面向公司内部用户的应用。比如内部数据管理平台、广告投放平台等。相比在线业务应用，其特点是数据保密性高，压力小并发量小，允许故障的发生

业务应用是基于后端的基础框架进行开发的，针对后端开发人员来说，有以下几种框架

• mvc框架：是统一的开发流程，提供开发效率、评比一些关键细节的web/后端开发框架。典型的mvc框架就是spring mvc、jersey、国外牛人开发的JFinal以及阿里的webX
• IOC框架：可以实现依赖注入、控制反转的框架。Java中最流行的spring框架提供的就是IOC功能
• ORM框架：是能够屏蔽底层数据库细节、提供统一的数据访问接口的数据库操作框架，另外也能狗支持客户端主从、分库、分表等分布式特性。Mybatis是目前最流行的ORM框架。此外，spring ORM总提供的jdbcTemplate也很不错。当然，对于分库分表，只从分离这些需求，一般需要自己去实现，开元的则有阿里巴巴的TDDL,当前的Sharding_JDBC(从DataSource层面解决了分库分表，读写分析的问题，对应用透明，零侵入)。此外，为了在服务层面统一解决分库分表，读/写分离，准备切换，缓存、故障恢复的等问题，很多公司都开发了自己的数据库中间件，比如阿里的cabar、360的Atilas,网易的DDB等;开源的则有Macat和KingShard,其中KingShard已经有一定的线上使用规模。mysql官方也提供了mysql proxy,可以使用lua脚本自定义主从、读写分离、分区这些逻辑，但性能较差，目前使用较少。
• 缓存框架：对Redis、MeMcached这些缓存软件的统一封装，能够支持客户端分布式方案、主从等。一般使用Spring的RedisTemplate即可，也可以使用Jedis做自己的封装，支持客户端分布式方案、主从等等。
• java EE 应用性能检测框架：对于线上的javaEE应用，需要一个统一的框架集成到一个业务中检测每一个请求、方法调用，jdbc链接，Redis链接等的耗时、状态等。Jwebap是一个性能检测工具，但是由于其很多年没有更新，可能不适用于现有的业务。

1.1.3缓存、数据库、搜索引擎、消息队列

缓存、数据库、搜索引擎、消息队列这4着都是应用依赖的后端基础服务，他们的性能直接影响到应用的整体性能，有时候代码写的再好也可能应为这些服务导致应用性能提升不上去

• 缓存：缓存通常被用来解决热点数据的访问问题，是提供数据库查询性能的强大武器。在高并发的后端应用中，将数据持久层的售加载到缓存中，能够隔离高并发请求与后端数据库，避免数据库被大量请求击垮、目前除了内存中的本地缓存，比较普遍的缓存软件有Memcached和Redis,其中redis已经成为最流行的缓存软件
• 数据库： 数据库可以说是后端应用组基本的基础设施、基本上绝大多数业务数据都是持久化存储在数据库中的。主流的数据库包括传统的关系数据库（MySQL，PostgresSQL）以及最近几年流行的NoSQL（MongoDB,HBase）.其中HBse是基于大数据领域的列数据库，受限于器查询性能，一般并不用于做业务数据库。
• 搜索引擎：搜索引擎是针对全文检索以及数据各种维度查询设计的软件。目前用的比较多的开源软件是Solr和Elasticsearch,他们都是自己与lucene来实现的，不同之处主要在于Term index的存储，分布式架构的支持等。ElastucSeach是对于不同集群的良好支持以及高性能的实现，已经逐渐成为搜索引擎的开源主流方案。
• 消息队列：数据传输的一种方式就是通过消息队列。目前用的比较普遍的消息队列包括为日志设计的Kafka以及重事物的RabbitMQ等。在对消息队列不是特别敏感且不要求消息事物的场景下，选择Kafka能够获得更高的性能；否则，RabbitMQ则是更好的选择。

1.1.4 文件存储

不管是业务应用、依赖的后端服务还是其他的各种服务，最终都是要依赖于底层文件存储。通常来讲，文件存储需要满足的特性有：可靠性、容灾性、稳定性，即要保证服务的数据不轻易丢失发生故障也能够快速回滚恢复，也要保证高可用。在底层可以采用传统的RAID作为解决方案，再上一层，目前的Hadoop的HDFS则是最普遍的分布式文件存储方案，当然还有NFS，Samba这种共享文件系统也提供了简单的分布式存储特性。
此外，如果文件存储缺失成为了引用的瓶颈，或者必须提供文件存储的性能从而提升整个系统的性能，那么最直接的和简单的做法就是排期传统机械硬盘，用SSD硬盘地体。像现在很多公司解决业务性能问题的时候，最终的关键点往往就是在SSD，这也是用钱换件时间和人力成本最直接和最有效的方式，在数据部分描述SSDB，就是对LevelDB封装以后，利用SSD硬盘特性的一种高兴KV数据库。
至于HDFS,如果要使用上面的数据，需要通过Hadoop实现。类型XX on YRAN的一些技术就是非Hadoop的技术跑在HDFS上的解决方案。

1.1.5

统一认证中心，主要是对app用户，内部用户，app等的认证服务，包括

• 用户的注册，登录验证，Token鉴权
• 内部信息系统用户的管理和登录鉴权
• app的管理，包括app的secret生成，APP的信息验证（如验证接口签名）等。
  之所以需要统一认证中心，就是为了能够对所有app都会用到的信息进行管理，页给所有应用提供统一的认证服务。尤其是在有很多特务需要共享用户数据的时候，构建一个统一认证中心是非常必要的。此外，通过统一认证中心构建移动的app的单点登录也是水到渠成的事情：模仿web的机制，将认证后的信息加密存储到本地存储中，供多个APP使用。