关于java:互联网后端技术栈一览写得太好了

应用 Java 后端技术的目标就是构建业务利用，为用户提供在线或者离线服务。因而，一个业务利用须要哪些技术、依赖哪些基础设施就决定了须要把握的后端技术有哪些。

纵观整个互联网技术体系再联合公司的目前情况，笔者认为必不可少或者十分要害的后端根底技术 / 设施如下图所示：

这里的后端基础设施次要指的是利用在线上稳固运行须要依赖的要害组件或者服务。开发或者搭建好以上的后端基础设施，个别状况下是可能撑持很长一段时间内的业务的。此外，对于一个残缺的架构来说，还有很多利用感知不到的零碎根底服务，如负载平衡、自动化部署、系统安全等，并没有蕴含在本章的形容范畴内。

1. 对立申请入口 -API 网关

在挪动 APP 的开发过程中，通常后端提供的接口须要以下性能的反对：

• 负载平衡
• API 拜访权限管制
• 用户鉴权

个别的做法，应用 Nginx 做负载平衡，而后在每个业务利用里做 API 接口的拜访权限管制和用户鉴权，更优化一点的形式则是把后两者做成公共类库供所有业务调用。但从总体上来看，这三种个性都属于业务的公共需要，更可取的形式则是集成到一起作为一个服务，既能够动静地批改权限管制和鉴权机制，也能够缩小每个业务集成这些机制的老本。这种服务就是 API 网关，能够抉择本人实现。也能够应用开源软件实现，如 Kong 和 Netflix Zuul。API 网关个别架构如下图所示：

然而以上计划的一个问题是因为所有 API 申请都要通过网关，它很容易成为零碎的性能瓶颈。因而，能够采取的计划是：去掉 API 网关，让业务利用间接对接对立认证核心，在根底框架层面保障每个 API 调用都须要先通过对立认证核心的认证，这里能够采取缓存认证后果的形式防止对对立认证核心产生过大的申请压力。

2. 业务利用和后端根底框架

业务利用分为：在线业务利用和外部业务利用。

• 在线业务利用：间接面向互联网用户的利用、接口等，典型的特点就是：申请量大、高并发、对故障的容忍度低。
• 外部业务利用：次要面向公司外部用户的利用。比方，外部数据管理平台、广告投放平台等。相比起在线业务利用，其特点: 数据保密性高、压力小、并发量小、容许故障的产生。

业务利用基于后端的根底框架开发，针对 Java 后端来说，应该有以下几个框架：

• MVC 框架：对立开发流程、进步开发效率、屏蔽一些要害细节的 Web/ 后端框架。典型的如 SpringMVC、Jersey 以及国人开发的 JFinal 以及阿里的 WebX。
• IOC 框架：实现依赖注入 / 管制反转的框架。Java 中最为风行的 Spring 框架的外围就是 IOC 性能。
• ORM 框架：可能屏蔽底层数据库细节，提供对立的数据拜访接口的数据库操作框架，额定地可能反对客户端主从、分库、分表等分布式个性。MyBatis 是目前最为风行的 ORM 框架。此外，Spring ORM 中提供的 JdbcTemplate 也很不错。当然，对于分库分表、主从拆散这些需要，个别就须要本人实现，开源的则有阿里的 TDDL、当当的 sharding-jdbc（从 datasource 层面解决了分库分表、读写拆散的问题，对利用通明、零侵入）。此外，为了在服务层面对立解决分库分表、读写拆散、主备切换、缓存、故障复原等问题，很多公司都是有本人的数据库中间件的，比方阿里的 Cobar、360 的 Atlas（基于 MySQL-Proxy）、网易的 DDB 等；开源的则有 MyCat（基于 Cobar）和 Kingshard, 其中 Kingshard 曾经有肯定的线上应用规模。MySQL 官网也提供了 MySQL Proxy, 能够应用 lua 脚本自定义主从、读写拆散、分区这些逻辑，但其性能较差，目前应用较少。
• 缓存框架：对 Redis、Memcached 这些缓存软件操作的对立封装，可能反对客户端分布式计划、主从等。个别应用 Spring 的 RedisTemplate 即可，也能够应用 Jedis 做本人的封装，反对客户端分布式计划、主从等。
• JavaEE 利用性能检测框架：对于线上的 JavaEE 利用，须要有一个对立的框架集成到每一个业务中检测每一个申请、办法调用、JDBC 连贯、Redis 连贯等的耗时、状态等。Jwebap 是一个能够应用的性能检测工具，但因为其曾经很多年没有更新，有可能的话倡议基于此我的项目做二次开发。

一般来说，以上几个框架即能够实现一个后端利用的雏形。

3. 缓存、数据库、搜索引擎、音讯队列

缓存、数据库、搜索引擎、音讯队列这四者都是利用依赖的后端根底服务，他们的性能间接影响到了利用的整体性能，有时候你代码写的再好兴许就是因为这些服务导致利用性能无奈晋升下来。

• 缓存：缓存通常被用来解决热点数据的拜访问题，是进步数据查问性能的弱小武器。在高并发的后端利用中，将数据长久层的数据加载到缓存中，可能隔离高并发申请与后端数据库，防止数据库被大量申请击垮。目前罕用的除了在内存中的本地缓存，比拟广泛的集中缓存软件有 Memcached 和 Redis。其中 Redis 曾经成为最支流的缓存软件。
• 数据库：数据库能够说是后端利用最根本的基础设施。基本上绝大多数业务数据都是长久化存储在数据库中的。支流的数据库包含传统的关系型数据库（MySQL、PostgreSQL）以及最近几年开始风行的 NoSQL（MongoDB、HBase）。其中 HBase 是用于大数据畛域的列数据库，受限于其查问性能，个别并不用来做业务数据库。
• 搜索引擎：搜索引擎是针对全文检索以及数据各种维度查问设计的软件。目前用的比拟多的开源软件是 Solr 和 Elasticsearch，都是基于 Lucence 来实现的，不同之处次要在于 termIndex 的存储、分布式架构的反对等。Elasticsearch 因为对集群的良好反对以及高性能的实现，曾经逐步成为搜索引擎的支流开源计划。
• 音讯队列：数据传输的一种形式就是通过音讯队列。目前用的比拟广泛的音讯队列包含为日志设计的 Kafka 以及重事务的 RabbitMQ 等。在对音讯失落不是特地敏感且并不要求音讯事务的场景下，抉择 Kafka 可能取得更高的性能；否则，RabbitMQ 则是更好的抉择。此外，ZeroMQ 则是一种实现音讯队列的网络编程 Pattern 库，位于 Socket 之上，MQ 之下。

举荐一个 Spring Boot 基础教程及实战示例：
https://github.com/javastacks…

4. 文件存储

不论是业务利用、依赖的后端服务还是其余的各种服务，最终还是要依赖于底层文件存储的。通常来说，文件存储须要满足的个性有：可靠性、容灾性、稳定性，即要保障存储的数据不会轻易失落，即便产生故障也可能有回滚计划，也要保障高可用。在底层能够采纳传统的 RAID 作为解决方案，再上一层，目前 Hadoop 的 HDFS 则是最为广泛的分布式文件存储计划，当然还有 NFS、Samba 这种共享文件系统也提供了简略的分布式存储的个性。

此外，如果文件存储的确成为了利用的瓶颈或者必须进步文件存储的性能从而晋升整个零碎的性能时，那么最为间接和简略的做法就是摈弃传统机械硬盘，用 SSD 硬盘代替。像当初很多公司在解决业务性能问题的时候，最终的关键点往往就是 SSD。这也是用钱换取工夫和人力老本最间接和最无效的形式。在数据库局部形容的 SSDB 就是对 LevelDB 封装之后，利用 SSD 硬盘的个性的一种高性能 KV 数据库。

至于 HDFS，如果要应用下面的数据，是须要通过 Hadoop 的。相似 xx on Yarn 的一些技术就是将非 Hadoop 技术跑在 HDFS 上的解决方案。

5. 对立认证核心

对立认证核心，次要是对 APP 用户、外部用户、APP 等的认证服务，包含：

• 用户的注册、登录验证、Token 鉴权
• 外部信息系统用户的治理和登录鉴权
• APP 的治理，包含 APP 的 secret 生成，APP 信息的验证（如验证接口签名）等。

之所以须要对立认证核心，就是为了可能集中对这些所有 APP 都会用到的信息进行治理，也给所有利用提供对立的认证服务。尤其是在有很多业务须要共享用户数据的时候，构建一个对立认证核心是十分必要的。此外，通过对立认证核心构建挪动 APP 的单点登录也是瓜熟蒂落的事件：模拟 Web 的机制，将认证后的信息加密存储到本地存储中供多个 APP 应用。

6. 单点登录零碎

目前很多大的在线 Web 网站都是有单点登录零碎的，艰深的来说就是只须要一次用户登录，就可能进入多个业务利用（权限能够不雷同），十分不便用户的操作。而在挪动互联网公司中，外部的各种治理、信息系统甚至内部利用同样也须要单点登录零碎。

目前，比拟成熟的、用的最多的单点登录零碎应该是耶鲁大学开源的 CAS, 能够基于 https://github.com/apereo/cas… 来定制开发的。

基本上，单点登录的原理都相似下图所示：

7. 对立配置核心

在 Java 后端利用中，一种读写配置比拟通用的形式就是将配置文件写在 Propeties、YAML、HCON 等文件中，批改的时候只须要更新文件重新部署即可，能够做到不牵扯代码层面改变的目标。对立配置核心，则是基于这种形式之上的对立对所有业务或者根底后端服务的相干配置文件进行治理的对立服务, 具备以下个性：

• 可能在线动静批改配置文件并失效
• 配置文件能够辨别环境（开发、测试、生产等）
• 在 Java 中能够通过注解、XML 配置的形式引入相干配置

百度开源的 Disconf 和携程的 Apollo 是能够在生产环境应用的计划，也能够依据本人的需要开发本人的配置核心，个别抉择 Zookeeper 作为配置存储。

8. 服务治理框架

对于内部 API 调用或者客户端对后端 API 的拜访，能够应用 HTTP 协定或者 RESTful（当然也能够间接通过最原始的 socket 来调用）。但对于外部服务间的调用，个别都是通过 RPC 机制来调用的。目前支流的 RPC 协定有：

• RMI
• Hessian
• Thrift
• Dubbo

这些 RPC 协定各有优劣点，须要针对业务需要做出最好的抉择。

这样，当你的零碎服务在逐步增多，RPC 调用链越来越简单，很多状况下，须要不停的更新文档来保护这些调用关系。一个对这些服务进行治理的框架能够大大减少因而带来的繁琐的人力工作。

传统的 ESB（企业服务总线）实质就是一个服务治理计划，但 ESB 作为一种 proxy 的角色存在于 Client 和 Server 之间，所有申请都须要通过 ESB，使得 ESB 很容易成为性能瓶颈。因而，基于传统的 ESB，更好的一种设计如下图所示：

如图，以配置核心为枢纽，调用关系只存在于 Client 和提供服务的 Server 之间，就防止了传统 ESB 的性能瓶颈问题。对于这种设计，ESB 应该反对的个性如下：

• 服务提供方的注册、治理
• 服务消费者的注册、治理
• 服务的版本治理、负载平衡、流量管制、服务降级、资源隔离
• 服务的容错、熔断

阿里开源的 Dubbo 则对以上做了很好的实现，也是目前很多公司都在应用的计划；当当网的扩大我的项目 Dubbox 则在 Dubbo 之上退出了一些新个性。目前，Dubbo 曾经被阿里奉献给 Apache，处于 incubating 状态。在运维监控方面，Dubbo 自身提供了简略的治理控制台 dubbo-admin 和监控核心 dubbo-monitor-simple。Github 上的 dubboclub/dubbokeeper 则是在其之上开发的更为弱小的集治理与监控于一身的服务治理以及监控零碎。

此外，Netflix 的 Eureka 也提供了服务注册发现的性能，其配合 Ribbon 能够实现服务的客户端软负载平衡，反对多种灵便的动静路由和负载平衡策略。

9. 对立调度核心

在很多业务中，定时调度是一个十分广泛的场景，比方定时去抓取数据、定时刷新订单的状态等。通常的做法就是针对各自的业务依赖 Linux 的 Cron 机制或者 Java 中的 Quartz。对立调度核心则是对所有的调度工作进行治理，这样可能对立对调度集群进行调优、扩大、工作治理等。Azkaban 和 Yahoo 的 Oozie 是 Hadoop 的流式工作治理引擎，也能够作为对立调度核心来应用。当然，你也能够应用 Cron 或者 Quartz 来实现本人的对立调度核心。

• 依据 Cron 表达式调度工作
• 动静批改、进行、删除工作
• 反对工作分片执行
• 反对工作工作流：比方一个工作实现之后再执行下一个工作
• 工作反对脚本、代码、url 等多种形式
• 工作执行的日志记录、故障报警

对于 Java 的 Quartz 这里须要阐明一下：这个 Quartz 须要和 Spring Quartz 辨别，后者是 Spring 对 Quartz 框架的简略实现也是目前应用的最多的一种调度形式。但其并没有做高可用集群的反对。而 Quartz 尽管有集群的反对，然而配置起来非常复杂。当初很多计划都是应用 Zookeeper 来实现 Spring Quartz 的分布式集群。

此外，当当网开源的 elastic-job 则在根底的散布式调度之上又退出了弹性资源利用等更为弱小的性能。

10. 对立日志服务

日志是开发过程必不可少的货色。打印日志的机会、技巧是很能体现出工程师编码程度的。毕竟，日志是线上服务可能定位、排查异样最为间接的信息。

通常的，将日志扩散在各个业务中十分不不便对问题的治理和排查。对立日志服务则应用独自的日志服务器记录日志，各个业务通过对立的日志框架将日志输入到日志服务器上。

能够通过实现 Log4j 或者 Logback 的 Appender 来实现对立日志框架，而后通过 RPC 调用将日志打印到日志服务器上。

11. 数据基础设施

数据是最近几年十分火的一个畛域。从《精益数据分析》到《增长黑客》，都是在强调数据的不凡作用。很多公司也都在通过数据推动产品设计、市场经营、研发等。这里须要阐明的一点是，只有当你的数据规模真的到了单机无奈解决的规模才应该上大数据相干技术，千万不要为了大数据而大数据。很多状况下应用单机程序 +MySQL 就能解决的问题非得上 Hadoop 即浪费时间又节约人力。

这里须要补充一点的是，对于很多公司，尤其是离线业务并没有那么密集的公司，在很多状况下大数据集群的资源是被节约的。因而诞了 xx on Yarn 一系列技术让非 Hadoop 系的技术能够利用大数据集群的资源，可能大大提高资源的利用率，如 Docker on Yarn。

数据高速公路

接着下面讲的对立日志服务，其输入的日志最终是变成数据到数据高速公路上供后续的数据处理程序生产的。这两头的过程包含日志的收集和传输。

• 收集：对立日志服务将日志打印在日志服务上之后，须要日志收集机制将其集中起来。目前，常见的日志收集计划有：Scribe、Chukwa、Kakfa 和 Flume。对比方下图所示：

此外，Logstash 也是一个能够抉择的日志收集计划，不同于以上的是，它更偏向于数据的预处理，且配置简略、清晰，常常以 ELK（Elasticsearch + Logstash + Kibana）的架构用于运维场景中。

• 传输：通过音讯队列将数据传输到数据处理服务中。对于日志来说，通常抉择 Kafka 这个音讯队列即可。

此外，这里还有一个要害的技术就是数据库和数据仓库间的数据同步问题，行将须要剖析的数据从数据库中同步到诸如 Hive 这种数据仓库时应用的计划。能够应用 Apache Sqoop 进行基于工夫戳的数据同步，此外，阿里开源的 Canal 实现了基于 binlog 增量同步，更加适宜通用的同步场景，然而基于 Canal 还是须要做不少的业务开发工作。

离线数据分析

离线数据分析是能够有提早的，个别针对的是非实时需要的数据分析工作，产生的也是提早一天的报表。目前最罕用的离线数据分析技术除了 Hadoop 还有 Spark。相比 Hadoop，Spark 性能上有很大劣势，当然对硬件资源要求也高。其中，Hadoop 中的 Yarn 作为资源管理调度组件除了服务于 MR 还能够用于 Spark（Spark on Yarn），Mesos 则是另一种资源管理调度零碎。

对于 Hadoop，传统的 MR 编写很简单，也不利于保护，能够抉择应用 Hive 来用 SQL 代替编写 MR。而对于 Spark，也有相似 Hive 的 Spark SQL。

此外，对于离线数据分析，还有一个很要害的就是数据歪斜问题。所谓数据歪斜指的是 region 数据分布不均，造成有的结点负载很低，而有些却负载很高，从而影响整体的性能。解决好数据歪斜问题对于数据处理是很要害的。

实时数据分析

绝对于离线数据分析，实时数据分析也叫在线数据分析，针对的是对数据有实时要求的业务场景，如广告结算、订单结算等。目前，比拟成熟的实时技术有 Storm 和 Spark Streaming。相比起 Storm，Spark Streaming 其实实质上还是基于批量计算的。如果是对提早很敏感的场景，还是应该应用 Storm。除了这两者，Flink 则是最近很火的一个分布式实时计算框架，其反对 Exactly Once 的语义，在大数据量下具备高吞吐低提早的劣势，并且可能很好的反对状态治理和窗口统计，但其文档、API 治理平台等都还须要欠缺。

实时数据处理个别状况下都是基于增量解决的，绝对于离线来说并非牢靠的，一旦呈现故障（如集群解体）或者数据处理失败，是很难对数据恢复或者修复异样数据的。因而联合离线 + 实时是目前最广泛采纳的数据处理计划。Lambda 架构就是一个联合离线和实时数据处理的架构计划。

此外，实时数据分析中还有一个很常见的场景：多维数据实时剖析，即可能组合任意维度进行数据展现和剖析。目前有两种解决此问题的计划：ROLAP 和 MOLAP。

• ROLAP：应用关系型数据库或者扩大的关系型数据库来治理数据仓库数据，以 Hive、Spark SQL、Presto 为代表。
• MOLAP：基于数据立方体的多位存储引擎，用空间换工夫，把所有的剖析状况都物化为物理表或者视图。以 Druid、Pinot 和 Kylin 为代表，不同于 ROLAP（Hive、Spark SQL）, 其原生的反对多维的数据查问。

如上一大节所述，ROLAP 的计划大多数状况下用于离线数据分析，满足不了实时的需要，因而 MOLAP 是多维数据实时剖析的罕用计划。对于其中罕用的三个框架，比照如下：

其中，Druid 绝对比拟轻量级，用的人较多，比拟成熟。

数据即席剖析

离线和实时数据分析产生的一些报表是给数据分析师、产品经理参考应用的，然而很多状况下，线上的程序并不能满足这些需求方的需要。这时候就须要需求方本人对数据仓库进行查问统计。针对这些需求方，SQL 上手容易、易形容等特点决定了其可能是一个最为适合的形式。因而提供一个 SQL 的即席查问工具可能大大提高数据分析师、产品经理的工作效率。Presto、Impala、Hive 都是这种工具。如果想进一步提供给需求方更加直观的 ui 操作界面，能够搭建外部的 Hue。

12. 故障监控

对于面向用户的线上服务，产生故障是一件很重大的事件。因而，做好线上服务的故障检测告警是一件十分重要的事件。能够将故障监控分为以下两个层面的监控：

• 系统监控：次要指对主机的带宽、CPU、内存、硬盘、IO 等硬件资源的监控。能够应用 Nagios、Cacti 等开源软件进行监控。目前，市面上也有很多第三方服务可能提供对于主机资源的监控，如监控宝等。对于分布式服务集群（如 Hadoop、Storm、Kafka、Flume 等集群）的监控则能够应用 Ganglia。此外，小米开源的 OpenFalcon 也很不错，涵盖了系统监控、JVM 监控、利用监控等，也反对自定义的监控机制。
• 业务监控：是在主机资源层面以上的监控，比方 APP 的 PV、UV 数据异样、交易失败等。须要业务中退出相干的监控代码，比方在异样抛出的中央，加一段日志记录。

监控还有一个要害的步骤就是告警。告警的形式有很多种：邮件、IM、短信等。思考到故障的重要性不同、告警的合理性、便于定位问题等因素，有以下倡议：

• 告警日志要记录产生故障的机器 ID，尤其是在集群服务中，如果没有记录机器 ID，那么对于后续的问题定位会很艰难。
• 要对告警做聚合，不要每一个故障都独自进行告警，这样会对工程师造成极大的困扰。
• 要对告警做等级划分，不能对所有告警都做同样的优先级解决。
• 应用微信做为告警软件，可能在节俭短信老本的状况下，保障告警的达到率。

故障告警之后，那么最最要害的就是应答了。对于守业公司来说，24 小时待命是必备的素质，当遇到告警的时候，须要尽快对故障做出反馈，找到问题所在，并能在可控工夫内解决问题。对于故障问题的排查，基本上都是依赖于日志的。只有日志打的正当，个别状况下是可能很快定位到问题所在的，然而如果是分布式服务，并且日志数据量特地大的状况下，如何定位日志就成为了难题。这里有几个计划：

• 建设 ELK（Elasticsearch + Logstash + Kibana）日志集中剖析平台，便于疾速搜寻、定位日志。搭配 Yelp 开源的 Elastalert 能够实现告警性能。
• 建设分布式申请追踪零碎（也能够叫全链路监测零碎），对于分布式系统尤是微服务架构，可能极大的不便在海量调用中疾速定位并收集单个异样申请信息，也能疾速定位一条申请链路的性能瓶颈。唯品会的 Mercury、阿里的鹰眼、新浪的 WatchMan、Twitter 开源的 Zipkin 根本都是基于 Google 的 Dapper 论文而来，公众点评的实时利用监控平台 CAT 则在反对分布式申请追踪（代码侵入式）的根底上退出了细粒度的调用性能数据统计。此外，Apache 正在孵化中的 HTrace 则是针对大的分布式系统诸如 HDFS 文件系统、HBase 存储引擎而设计的分布式追踪计划。而如果你的微服务实现应用了 Spring Cloud，那么 Spring Cloud Sleuth 则是最佳的分布式跟踪计划。还须要提到的是，Apache 孵化中的 SkyWalking 是基于分布式追踪的一个齐备的 APM（利用性能监测）零碎，其最大的一个特点就是基于 Java agent + instrument api，对业务代码无任何侵入，Pinpoint 则是相似的另一个曾经用于生产环境的 APM 零碎。

起源：https://github.com/superhj198…

近期热文举荐：

1.1,000+ 道 Java 面试题及答案整顿 (2022 最新版)

2. 劲爆！Java 协程要来了。。。

3.Spring Boot 2.x 教程，太全了！

4. 别再写满屏的爆爆爆炸类了，试试装璜器模式，这才是优雅的形式！！

5.《Java 开发手册（嵩山版）》最新公布，速速下载！

感觉不错，别忘了顺手点赞 + 转发哦！