使用Java后台技术的目的是构建业务应用，为用户提供线上或线下服务。因此，业务应用需要哪些技术，依赖哪些基础设施，决定了需要掌握的后端技术。结合公司现状纵观整个互联网技术体系，笔者认为必不可少或非常关键的后端基础技术/设施如下图所示：这里的后端基础设施主要是指应用稳定在线运行需要依赖。关键组件或服务。以上后端基础设施的开发或建设，一般可以长期支持业务。此外，对于一个完整的架构来说，还有很多基础的系统服务是不被应用感知的，比如负载均衡、自动化部署、系统安全等，不在本章的讨论范围之内。1、统一请求入口-API网关在手机APP开发过程中，后端提供的接口通常需要以下功能的支持：负载均衡API访问控制用户认证一般做法，使用Nginx进行负载均衡，然后在每个业务应用中，都完成了API接口的访问控制和用户认证。更优化的方式是将后两者做成一个公共类库，供所有业务调用使用。但是从整体上看，这三个特性属于业务的共同需求，更可取的方式是将它们集成在一起作为一个服务，这样既可以动态修改权限控制和认证机制，又可以减少访问的次数每个业务集成的服务。机制成本。这种服务就是API网关，你可以选择自己实现。也可以使用Kong和NetflixZuul等开源软件实现。API网关的总体架构如下图所示：但是上述方案的一个问题是，由于所有的API请求都经过网关，很容易成为系统的性能瓶颈。因此，可以采用的解决方案是：去掉API网关，让业务应用直接连接统一认证中心，在基础框架层面保证每次API调用都需要通过统一认证中心的认证。统一认证中心产生过大的请求压力。2、业务应用和后台基础设施业务应用分为：在线业务应用和内部业务应用。在线商务应用：直接面向互联网用户的应用和界面。典型的特点是：请求量大、并发度高、容错度低。内部业务应用：主要面向公司内部用户的应用。例如内部数据管理平台、广告平台等。与在线业务应用相比，其特点：数据保密性高、压力小、并发性低、允许故障。业务应用是基于后台的基础框架开发的。对于Java后端，应该有以下框架：MVC框架：统一开发流程，提高开发效率，屏蔽一些关键细节的web/后端框架。典型的例子有SpringMVC、Jersey、国人开发的JFinal、阿里的WebX。IOC框架：实现依赖注入/控制反转的框架。Java中最流行的Spring框架的核心是IOC功能。ORM框架：可以屏蔽底层数据库细节，提供统一的数据访问接口数据库操作框架，另外支持客户端主从、分库、分表等分布式特性。MyBatis是目前最流行的ORM框架。另外，SpringORM中提供的JdbcTemplate也很不错。当然对于分库分表，主从分离的需求，一般需要自己实现。开源的有阿里的TDDL和当当网的sharding-jdbc（从datasource层面解决分库分表，读写分离问题。对应用透明，零侵入）。另外，很多公司都有自己的数据库中间件，比如阿里的Cobar，360的Atlas等（基于MySQL-Proxy），网易的DDB等；开源的有MyCat（基于Cobar）和Kingshard，其中Kingshard已经有一定的在线使用规模。MySQL官方也提供了MySQLProxy，可以使用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之下。推荐一个SpringBoot基础教程和实例：https://github.com/javastacks...4.文件存储，无论是业务应用，依赖后端服务还是其他服务，最终还是要看底层文件存储。一般来说，文件存储需要满足的特性有：可靠性、容灾性和稳定性。即要保证存储的数据不会轻易丢失，即使发生故障也要有回滚计划，还要保证高可用。在底层，可以采用传统的RAID作为解决方案。再往上一层，Hadoop的HDFS是最常见的分布式文件存储方案。当然，NFS、Samba等共享文件系统也提供了简单的分布式存储。特征。另外，如果文件存储确实成为了应用的瓶颈或者必须提升文件存储的性能来提升整个系统的性能，那么最直接简单的方法就是摒弃传统的机械硬盘，取而代之固态硬盘。像现在很多公司一样，在解决业务性能问题的时候，最后的重点往往是SSD。这也是用金钱换取时间和人工成本最直接有效的方式。数据库部分介绍的SSDB是利用SSD硬盘特性封装LevelDB后的高性能KV数据库。至于HDFS，如果要使用上面的数据，需要通过Hadoop。xxonYarn等一些技术是在HDFS上运行非Hadoop技术的解决方案。5、统一认证中心统一认证中心主要为APP用户、内部用户、APP等提供认证服务，包括：用户注册、登录验证、token认证内部信息系统用户管理和登录认证APP管理，包括APP秘钥生成、APP信息验证（如验证接口签名）等。之所以需要一个统一的认证中心，是为了能够集中管理所有APP会用到的??信息，为所有应用提供统一的认证服务。尤其是当有很多业务需要共享用户数据时，建立一个统一的认证中心是非常有必要的。此外，通过统一的认证中心为移动应用构建单点登录也是水到渠成的事情：模仿Web的机制，将认证信息加密存储在本地存储，供多个应用使用。6.单点登录系统目前，许多大型在线网站都有单点登录系统。一般来说，只需一个用户登录即可进入多个业务应用（权限可以不同），非常方便用户操作。在移动互联网企业中，各种内部管理、信息系统乃至外部应用也都需要单点登录系统。目前比较成熟、使用最多的单点登录系统应该是耶鲁大学开源的CAS，可以基于https://github.com/apereo/cas进行定制开发...基本上就是单点的原理登录类似下图所示：7.统一配置中心在Java后端应用中，常见的配置读写方式是将配置文件写入Propeties、YAML、HCON等文件中，修改时，只需要更新文件，重新部署，就可以达到代码层面不涉及改动的目的。统一配置中心是基于这种方式的统一服务，统一管理所有业务或基础后端服务的相关配置文件。它具有以下特点：可以在线动态修改配置文件并生效。配置文件可以区分环境（开发、测试、生产等），在Java中可以通过注解和XML配置来引入相关配置。百度开源的Disconf和携程的Apollo都是可以在生产环境使用的解决方案，也可以根据自己的需要开发自己的配置中心。一般选择Zookeeper作为配置存储。8、服务治理框架对于外部API调用或者客户端访问后端API，可以使用HTTP协议或者RESTful（当然也可以通过最原始的socket直接调用）。但是内部服务之间的调用一般都是通过RPC机制来调用的。目前主流的RPC协议有：RMIHessianThriftDubbo这些RPC协议各有优缺点，需要根据业务需求做出最佳选择。这样当你的系统服务逐渐增多的时候，RPC调用链就会变得越来越复杂。在很多情况下，需要不断更新文档来维护这些调用关系。管理这些服务的框架可以大大减少由此产生的繁琐的手动工作。传统的ESB（EnterpriseServiceBus）本质上是一种服务治理方案，但是ESB作为Client和Server之间的代理存在，所有的请求都需要经过ESB，使得ESB很容易成为性能瓶颈。因此，在传统ESB的基础上，更好的设计如下图所示：如图所示，配置中心是枢纽，调用关系只存在于Client和提供服务的服务器之间，避免了传统ESB的性能瓶颈。对于这种设计，ESB应该支持以下特性：服务提供者注册、管理服务消费者注册、管理服务版本管理、负载均衡、流量控制、服务降级、资源隔离服务容错、融合阿里开源Dubbo在上面的实现上做得很好，也是目前很多公司都在使用的解决方案；当当网的扩展项目Dubbox为Dubbo增加了一些新特性。目前，Dubbo已被阿里贡献给Apache，处于孵化状态。在运维监控方面，Dubbo本身提供了一个简单的管理控制台dubbo-admin和一个监控中心dubbo-monitor-simple。Github上的dubboclub/dubbokeeper是一个比较强大的服务管理和监控系统，集管理和监控于一体。另外，Netflix的Eureka也提供了服务注册和发现的功能。配合Ribbon，可以实现服务的客户端软负载均衡，支持多种灵活的动态路由和负载均衡策略。9、统一调度中心在很多业务中，定时调度是一个很常见的场景，比如定时抓取数据，定时刷新订单状态等，通常的做法是依赖Linux的Cron机制或者Java中的Quartz为他们各自的业务。统一调度中心管理所有调度任务，实现调度集群统一调优、扩容、任务管理。Azkaban和Yahoo的Oozie是Hadoop的流式作业管理引擎，也可以作为统一的调度中心。当然你也可以使用Cron或者Quartz来实现自己的统一调度中心。根据Cron表达式调度任务动态修改、停止、删除任务支持任务分片执行支持任务工作流：比如一个任务完成后，会执行下一个任务Java的Quartz这里需要说明一下故障告警：这个Quartz需要和SpringQuartz区分开来，它是Spring对Quartz框架的简单实现，是目前使用最多的调度方式。但不支持高可用集群。虽然Quartz有集群支持，但是配置起来非常复杂。现在很多方案都是使用Zookeeper来实现SpringQuartz的分布式集群。另外，当当网开源的elastic-job在基础分布式调度的基础上，增加了弹性资源利用等更强大的功能。10、统一日志服务日志是开发过程中必不可少的东西。打印日志的时机和技巧可以反映工程师的编码水平。毕竟日志是在线服务定位和排查异常最直接的信息。通常，日志分散在各个业务中，管理和排查问题非常不方便。统一日志服务使用独立的日志服务器记录日志，各个业务通过统一的日志框架向日志服务器输出日志。统一的日志框架可以通过实现Log4j或者Logback的Appender来实现，然后通过RPC调用将日志打印到日志服务器。11.数据基础设施数据是近年来非常热门的领域。从《精益数据分析》到《增长黑客》，都在强调数据的非凡作用。很多企业也在利用数据推动产品设计、市场运营、研发等。这里需要说明的是，只有当你的数据规模真的达到单机无法处理的规模时，你才应该使用大数据相关技术，绝不能为了大数据而使用大数据。很多时候用单机程序+MySQL就能解决的问题，必须用Hadoop来解决，浪费时间和人力。这里需要补充的是，对于很多企业，尤其是线下业务不是很密集的企业来说，大数据集群的资源在很多情况下是被浪费的。因此诞生了xxonYarn等一系列技术，让非基于Hadoop的技术可以使用大数据集群的资源，可以大大提高资源利用率，比如DockeronYarn。数据高速公路遵循上面提到的统一日志服务，输出的日志最终转化为数据发送到数据高速公路，供后续数据处理程序消费。中间过程包括日志收集和传输。收集：统一日志服务在日志服务上打印日志后，需要一个日志收集机制来集中处理。目前常见的日志采集方案有：Scribe、Chukwa、Kakfa、Flume。对比如下图所示：另外，Logstash也是一个可选的日志收集方案。与上面不同的是，它更倾向于数据预处理，配置简单明了。常基于ELK（Elasticsearch+Logstash+Kibana）架构用于运维场景。传输：数据通过消息队列传输到数据处理服务。对于日志，通常选择Kafka的消息队列。另外，这里还有一个关键技术就是数据库和数据仓库的数据同步问题，也就是将待分析的数据从数据库同步到Hive等数据仓库时使用的方案。您可以使用ApacheSqoop进行基于时间戳的数据同步。另外，阿里开源的Canal实现了基于binlog的增量同步，更适合一般的同步场景。但是，基于Canal，还需要做大量的业务开发工作。离线数据分析离线数据分析可以延迟。一般针对非实时性要求的数据分析工作，报表的生成也有一天的延迟。目前最常用的离线数据分析技术包括Hadoop和Spark。与Hadoop相比，Spark在性能上有很大的优势，当然对硬件资源的要求也很高。其中，Hadoop中的Yarn作为资源管理调度组件，除了服务于MR外，还可以用于Spark（SparkonYarn），而Mesos则是另外一种资源管理调度系统。对于Hadoop，传统的MR写法非常复杂，不利于维护。您可以选择使用Hive来代替用SQL编写MR。对于Spark，还有类似于Hive的SparkSQL。此外，对于离线数据分析，还有一个关键问题就是数据倾斜问题。所谓数据倾斜，是指区域数据分布不均匀，导致部分节点负载低，部分节点负载高，影响整体性能。处理数据倾斜对于数据处理至关重要。实时数据分析与离线数据分析相比，实时数据分析也称为在线数据分析，针对的是广告结算、订单结算等需要实时数据的业务场景。目前比较成熟的实时技术有Storm和SparkStreaming。与Storm相比，SparkStreaming本质上是基于批计算的。如果是对延迟敏感的场景，还是应该使用Storm。除了这两者之外，Flink是最近流行的分布式实时计算框架。支持ExactlyOnce语义，具有大数据量下高吞吐、低延迟的优势，可以很好地支持状态管理和窗口统计，但其文档、API管理平台等仍需完善。实时数据处理一般都是基于增量处理，相比离线不可靠。一旦发生故障（如集群崩溃）或数据处理失败，很难恢复数据或修复异常数据。因此，离线+实时相结合是目前最常用的数据处理方案。Lambda架构是一种结合了离线和实时数据处理的架构解决方案。此外，实时数据分析还有一个非常常见的场景：多维数据实时分析，可以结合任意维度进行数据展示和分析。这个问题目前有两种解决方案：ROLAP和MOLAP。ROLAP：使用关系数据库或扩展关系数据库来管理数据仓库数据，以Hive、SparkSQL、Presto为代表。MOLAP：基于数据立方体的多位存储引擎，以空间换取时间，将所有分析情况具体化为物理表或视图。以Druid、Pinot、Kylin为代表，区别于ROLAP（Hive、SparkSQL），原生支持多维数据查询。上一节提到，ROLAP方案多用于离线数据分析，不能满足实时性要求。因此，MOLAP是多维数据实时分析的常用解决方案。三种常用框架对比如下：使用场景语言协议特性Druid实时处理分析JavaJSON实时聚合Pinot实时处理分析JavaJSON实时聚合KylinOLAP分析引擎JavaJDBC/OLAP预处理，缓存其中Druid比较轻量级，用的人比较多，也比较成熟。数据即席分析离线和实时数据分析生成的一些报告，供数据分析师和产品经理参考，但在很多情况下，在线程序无法满足这些需求者的需求。这时候需求方就需要自己去数据仓库查询统计了。对于这些需求方，SQL易学易描述，决定了它可能是最合适的方式。因此，提供一个即席的SQL查询工具，可以大大提高数据分析师和产品经理的工作效率。Presto、Impala和Hive都是此类工具。如果想进一步为需求方提供更直观的UI操作界面，可以构建内部Hue。12、故障监控对于面向用户的在线服务来说，故障是一件非常严重的事情。因此，做好在线服务的故障检测和告警工作非常重要。故障监控可分为以下两个级别的监控：系统监控：主要是指对主机的带宽、CPU、内存、硬盘、IO等硬件资源的监控。可以使用Nagios、Cacti等开源软件进行监控。目前市面上也有很多第三方服务可以提供主机资源的监控，比如监控宝。对于分布式服务集群（如Hadoop、Storm、Kafka、Flume等）的监控，可以使用Ganglia。另外，小米开源的OpenFalcon也很不错，涵盖了系统监控、JVM监控、应用监控等，还支持自定义监控机制。业务监控：是宿主机资源层面以上的监控，比如APPPV、UV数据异常、交易失败等，需要在业务中添加相关的监控代码，比如在抛出异常的地方添加日志记录。监控的另一个关键步骤是警报。告警方式有多种：邮件、IM、短信等。考虑到故障的不同严重程度、告警的合理性以及问题定位的难易程度，提出以下建议：告警日志应记录ID发生故障的机器，特别是在集群服务中。如果不记录机器ID，那么后续定位问题会比较困难。告警要聚合起来，不要对每个故障单独告警，这样会给工程师带来很大的麻烦。为了对告警进行分类，不能将所有告警都以相同的优先级对待。使用微信作为报警软件，可以在保证报警到达率的同时，节省短信费用。故障告警后，最关键的是处理。对于初创公司来说，24小时待命是必不可少的素质。当遇到告警时，他们需要第一时间响应故障，发现问题，并能够在可控的时间内解决问题。对于故障的排查，基本靠日志。只要日志设置得当，一般情况下可以很快定位问题。但是，如果是分布式服务，日志数据量特别大，那么如何定位日志就成了一个问题。这里有几种解决方案：建立ELK（Elasticsearch+Logstash+Kibana）日志集中分析平台，方便快速查找和定位日志。借助Yelp开源的Elastalert，可以实现报警功能。建立分布式请求跟踪系统（也称为全链路监控系统）。对于分布式系统，尤其是微服务架构，可以非常方便的在大量调用中快速定位和收集单个异常请求的信息，也可以快速定位一个请求环节的性能瓶颈。唯品会的Mercury、阿里的EagleEye、新浪的WatchMan、Twitter开源的Zipkin，基本上都是基于Google的Dapper论文。大众点评实时应用监控平台CAT支持分布式请求跟踪（代码侵入式）在.的基础上增加了细粒度的调用性能统计。此外，Apache正在孵化的HTrace是为HDFS文件系统、HBase存储引擎等大型分布式系统设计的分布式跟踪解决方案。而如果你的微服务实现使用了SpringCloud，那么SpringCloudSleuth是最好的分布式跟踪解决方案。还需要提到的是，Apache孵化下的SkyWalking是一个完整的基于分布式追踪的APM（ApplicationPerformanceMonitoring）系统。它最大的特点之一是基于Javaagent+instrumentapi，对业务代码没有任何侵入。是另一个类似的APM系统，已经在生产环境中使用过。来源：https://github.com/superhj198...近期热点文章推荐：1.1000+Java面试题及答案（2022最新版）2.厉害了！Java协程来了。..3.SpringBoot2.x教程，太全面了！4.不要用爆破爆满画面，试试装饰者模式，这才是优雅的方式！！5.《Java开发手册（嵩山版）》最新发布，赶快下载吧！感觉不错，别忘了点赞+转发！
