后端技术基础设施

  1. 请求统一入口
  2. 业务应用和后端基础框架
  3. 数据库
  4. 搜索引擎
  5. 消息队列
  6. 统一认证中心
  7. 单点登录系统
  8. 配置中心
  9. 服务治理框架
  10. 统一调度中心
  11. 故障监控

请求统一入口

一般的做法是,使用 nginx 做负载均衡,然后在每个业务应用里面做 API 接口的访问权限控制和用户鉴权(诸侯分封制),更优化一点的方式则是把后者做成公共类库供所有业务调用(中央下派人员驻点,打成 lib\maven 被复用)。但从总体上看,这三种特性都属于业务的公共需求,更可取的方式则是集成到一起作为一个服务(中央集权制,就是微服务中的 gateway),这样既可以动态地修改权限控制和鉴权机制,也可以减少每个业务集成这些机制的成本。

所有的请求都要经过 API网关,容易造成性能瓶颈。可采取的方案是去掉 API网关,让业务应用直接对接统一认证中心,在基础框架层面保证每个调用都需要先通过统一认证中心的认证,这里可以采取缓存认证结果的方式避免对统一认证中心产生过大的请求压力。

业务应用和后端基础框架

mvc 框架:主要是提升开发效率,经典的 spring mvc、国人开发的 jfinal 以及阿里的 webx
ioc 框架:主要是开发解耦,经典的 spring
orm 框架:mybatis 是目前最流行的 orm 框架,spring orm 提供的 jdbctemplate 也很不错,当当的 sharding-jdbc(从 DataSource 层面解决了分库发表、读/写分离、对应用透明、零入侵)。还有些从服务层统一解决的框架,阿里的 cobar,360 的 atlas,网易的 ddb,开源的 mycat 和 kingshard(有一定规模),mysql 官方的 mysql proxy(使用 lua 脚本自定义要实现的功能,性能太差了,没什么人用)
缓存框架:一般使用 spring redisTemplate,也可以使用 jedis 自己封装
java ee 应用性能检测框架:jwebap 是一个可以使用的性能检测工具,但由于其已经很多年没有关系,有可能的话建议基于此项目做二次开发

数据库

主要是关系型数据库 mysql、postresql 以及最近几年流行的非关系型数据库 MongoDB、HBASE(大数据领域的列数据库,受限于其查询性能,一般并不用于做业务数据库)

可以说,正确的使用所有就基本等于掌握了数据库的使用,目前绝大多数数据库都使用了B树作为所有的数据结构,目的就是为了利用磁盘顺序读/写的特性。

搜索引擎

目前开源的有 solar 和 elasticsearch,它们都是基于 Lucene。由于 elasticsearch 对于集群的良好支持以及高性能实现,已经逐渐成为主流开源方案。

消息队列

对消息丢失不是特别敏感并且不要求消息事务的场景下,选择 kafka 能获得更好的性能;否则用 rabbitmq。

具体情况下,建议结合技术生态,比如我现在在用 spring cloud alibaba 全家桶,因此消息队列选择了 rocketmq。

统一认证中心

主要是对 APP 用户、内部用户、APP 等的认证服务,包括:

  • 用户注册、登录验证、token 鉴权
  • 内部消息系统用户的管理和登录鉴权
  • app 的管理,包括 app 的 secret 生成、app 信息的验证

单点登录系统

用户登录一次就可以进入多个业务应用(权限可以不同),非常方便用户操作,比较成熟的如耶鲁大学的 cas。

配置中心

通常来说,配置都是保存在 propeties、yaml 中,有个弊端就是修改后要重启项目,基于阿里的 nacos 这样的框架就可以在线修改并且实时生效。

服务治理框架

目前主流的 rpc 协议有:

  • rmi
  • hessian
  • thrift
  • dubbo

传统的 esb(企业服务总线)本质上就是一个服务治理方案,但它作为代理的角色存在于 client 和 server 之间,所有请求都需要经过它,容易造成性能瓶颈。

统一调度中心

定时调度是一个非常普遍的场景。通常的做法是针对各自的服务,依赖 linux cron 或者 java quartz 来调度。spring quartz 是对 quartz 的简单实现,目前比较主流,但是呢没有集群功能,现在很多方案使用 zookeeper 来实现分布式集群。

故障监控

系统监控,比如带宽、cpu、内存、硬盘…,目前主流的推荐使用 zabbix、nagios、小米的 openfalcon。

业务监控,比如 app 的 pv、uv 数据异常、交易失败等,监控有一个重要的环节就是告警。告警要考虑故障的重要性差异、告警的合理性、告警的方式等因素。有几点需要注意:

  • 告警日志要记录发生故障的机器 id,尤其在集群服务中,没有记录机器 id 那么对于后续问题的定位会非常困难。
  • 告警要做聚合,不要每一个故障都单独的进行告警,这样会对工程师造成极大的困扰。
  • 告警要做等级划分,不能对所有告警都做同样的优先级处理。
  • 使用微信作为告警软件,能够在节约短信成本的情况下,保障告警的到达率。

告警之后最重要的就是如何应对,对于创业公司来说,24小时待命是必备的素质。一般来说,只要日志合理就能很快定位到问题所在,但是如果是分布式服务,并且日志量很大,那么就会有点困难。建议的解决方案:

  • 建立 elk 日志集成分析平台
  • 建立分布式请求追踪系统(全链路监测系统)。唯品会的 mercury、阿里的鹰眼、新浪的 watchman、twitter 的 zipkin、苹果正在孵化中的 htrace。如果是微服务架构,并且也使用了 spring cloud,那么建议使用 spring cloud sleuth。

转载请注明来源。 欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。 可以在下面评论区评论,也可以邮件至 sharlot2050@foxmail.com。

文章标题:后端技术基础设施

字数:1.5k

本文作者:夏来风

发布时间:2021-02-16, 23:41:36

原始链接:http://www.demo1024.com/blog/java-guide-base/

版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。