作者：杭建
出版社：电子工业出版社
格式: AZW3, DOCX, EPUB, MOBI, PDF, TXT
Java工程师修炼之道试读：
前言
目前互联网行业如火如荼，进入这个行业的技术人员也越来越多。对于研发来说，从工程角度其主要分为前端工程师、客户端工程师（又分为iOS和Android工程师）、后端工程师、算法工程师等职位。本书所说的Java工程师指的是以Java作为主要开发语言的后端工程师。
笔者从2008年还未毕业时做一些小的项目至今，做后端开发已经有差不多10年时间。经历过刚学Java时的迷茫，第一次写出Java程序时的激动，第一次写出一个Web系统的醍醐灌顶，一直到接触Java更底层的东西，总的来说对Java有了系统性的认识，对后端技术体系有了宏观的感受。这期间，笔者用过各种各样的编程语言，尝试过各种开源软件，挖过各种坑，也填过各种坑。针对后端技术来说，笔者认为自己的这些知识体系，还是有一定价值的。
此外，还记得当笔者毕业后进入第一家公司时，入职培训的课程虽然不难，但确实有种恍然大悟的感觉。业界的最佳实践和自己在学校里学到的、使用到的知识，差别还是非常大的。直到后来加入现在的这家公司，给新老员工做过一系列后端技术的培训课程，在校招的笔试和面试过程中深刻体会到学校与业界脱节之严重，在平时的社招中遇到很多对后端技术缺乏系统性认识、技能点不足的工程师，并且也经常被人问起如何学习Java后端技术，于是就打算将目前后端工程师一些比较主流、前沿的技术以及实际工作中会用到的技能串联起来，给刚上大学以后打算以Java后端为职业的学生、刚毕业入职的应届生以及初学者们一些入门的指引，使其少走弯路。另外也希望给一些有经验的工程师提供一个参考手册，将零散的知识点串起来，减少在解决某些实际问题时无头绪搜索带来的时间成本，同时也是对自己的一个阶段性总结和查漏补缺。需要注意的一点是，像数据结构、计算机网络等计算机科学基础知识以及Java SE的基本用法，笔者认为是从事程序开发工作的Java工程师应该必备的知识，因此并不包括在内。
本书会针对Java后端开发工作中经常用到的关键技能点做阐述，会尽量覆盖实际工作中需要的所有技能。但由于很多技能并非一两个章节就能完整讲述，因此本书仅做一些实践性的经验总结和阐述，更加详细和深入的学习则需要参考专门的书籍或者官方文档。
本书的大部分内容都来自笔者的博客以及平时工作、学习中的一些自我总结和笔记，记录了笔者进入这个行业以来的一些经验教训和思考。
面向读者
● 未入门或者刚入门的Java工程师
包括未来以Java后端开发为职业方向的在校学生、刚毕业入职的Java工程师以及未形成知识体系的Java工程师。这类读者通过阅读本书能够对Java工程师的必备技能有一个全局认识，逐步形成自己的Java技术体系。
· 有经验的Java工程师
有经验的Java工程师可以通过本书查漏补缺，巩固自己的开发技能，进一步完善自身的Java技术体系。
· 对Java后端开发感兴趣的非Java工程师
非Java工程师可以通过本书了解Java工程师的技能体系，尤其对于其他语言的后端工程师来说，本书的很多内容也是通用的，并不局限于Java开发。
内容概览
● 第1章 后端技术导言
本章主要从总体上描述后端技术的概念、组成、作用、需要的知识点，并给出了学习后端技术的建议。
· 第2章 Java项目与工程化
本章主要讲述Java项目与工程化需要掌握的软件、技能等。
· 第3章 开发框架
本章主要讲述Java后端开发中的一些主流框架的使用方法。
· 第4章 Spring
本章主要讲述Spring核心、数据操作以及一些常用组件的使用。
· 第5章 数据存储
本章主要讲述Java应用中数据存储上使用的一些软件、服务等。
· 第6章 数据通信
本章主要讲述Java应用中数据传输、通信上使用的一些软件、服务等。
· 第7章 Java编程进阶
本章主要介绍一些Java开发中的高级特性以及在Java开发中非常流行的类库。
· 第8章 性能调优
本章主要讲述如何对Java应用的性能进行分析和调优，并给出了开发建议。
· 第9章 安全技术
本章主要对Java开发中常用的加密技术、HTTPS以及防范各种攻击的方案做了阐述。
参考资料
在写作本书的过程以及平时的工作中，笔者阅读、参考过很多书籍，以下是其中具有代表性的一些书籍。对于本书讲述不够深入的地方，可以参考这些书籍进一步学习。
● 《Effective Java（第2版）》：此书讲解了Java的一些高级特性和技巧。
· 《Java并发编程实战》：此书是并发编程经典书籍，涵盖了并发编程的各种知识点以及相关理论知识。
· 《七周七并发模型》：此书讲述了主流的7种并发编程模式。
· 《深入理解Java虚拟机：JVM高级特性与最佳实践（第2版）》：此书讲解了JVM的内存、GC、字节码、编译器等高级特性和优化实践。
· 《高性能MySQL（第3版）》：此书讲述了MySQL各种优化技巧，并结合原理给予讲解。
· 《Redis开发与运维》：此书在原理层面对于Redis的使用、优化做了详尽的描述。
· 《深入理解Elasticsearch（原书第2版）》：此书讲述了对Elasticsearch的使用、原理和优化技巧。
· 《Java性能权威指南》：此书是Java性能调优的权威书籍，几乎涵盖了Java调优的方方面面。
· 《构建高性能Web站点（修订版）》：此书从各种案例出发，讲解了高性能Web站点需要的各种优化技巧、实践经验等。
· 《白帽子讲Web安全》：此书基本涵盖了Web安全技术的方方面面，包括客户端安全、服务器端安全等。
虽然以上书籍都是非常实用的参考资料，但就笔者自己来看，更为推崇的则是直接通过相关技术的官方文档来学习，这样既能够锻炼自己的英文阅读能力，又能够直面相关技术的第一手文档，避免了在看相关书籍时被一些偶然的纰漏所误导。
此外，上面的《Effective Java（第2版）》和《Java并发编程实战》这两本书都是基于Java的旧版本来写作的，但是里面介绍的很多内容并不过时，尤其是JDK底层源码、设计理论、优化思想等仍然适用于现在的Java开发。
勘误和支持
在本书的写作过程中，笔者一直是战战兢兢的，一直害怕写成那种侃侃而谈却没有实质内容的东西或者传递给读者一些误导信息，因此对于每一个知识点，都是在查阅官方文档以及其他权威资料并经过自己深入思考之后才敢落笔的。但由于笔者知识能力有限，难免有错误和疏漏，希望得到各位读者的理解和指正。
如果在阅读本书的过程中发现错误，请提交到网址https：//github.com/superhj1987/pragmatic-java-engineer/issues或博文视点官网本书页面。
同时，请随时注意勘误信息的发布：https：//github.com/superhj1987/pragmatic-java-engineer/wiki/Mistakes。
致谢
由于工作以及个人身体等方面的原因，中间数次延期，历时一年多才完成本书。因此首先要特别感谢笔者的父母和妻子，在笔者写作本书的过程中给予了非常大的后勤支持和鼓励，让笔者能够专心地完成写作。
同时要感谢中华万年历的同事们在平时的工作中给了笔者很多启发和思路，感谢公司的设计总监张喜亮抽出时间帮助修饰了一些图片，尤其要感谢CEO孙建在本书写作过程中给予笔者了充分的信任和支持。
还要感谢笔者的前同事，也是笔者刚毕业时的工作导师尧飘海，他在百忙之中审阅了本书并给本书写序；也要感谢前同事张小川、阙杭宁和好友秦绪震、饶洵，他们抽出了宝贵的业余时间校对了本书并给出了很有价值的建议。
最后，感谢电子工业出版社永恒的侠少，他找到我出版本书，并允许我一次次延期。也感谢付睿编辑的辛苦校对和修改，让本书得以顺利出版。
也把本书献给我刚出生的女儿——依依。
联系方式
邮箱：superhj1987@126.com
博客：http：//rowkey.me
微博：http：//weibo.com/superhj1987
读者服务
轻松注册成为博文视点社区用户（www.broadview.com.cn），您即可享受以下服务。
● 下载资源：本书如提供示例代码及资源文件，均可在下载资源处下载。
· 提交勘误：您对书中内容的修改意见可在提交勘误处提交，若被采纳，将获赠博文视点社区积分（在您购买电子书时，积分可用来抵扣相应金额）。
· 交流互动：在页面下方读者评论处留下您的疑问或观点，与我们和其他读者一同学习交流。
页面入口：http：//www.broadview.com.cn/33501第1章后端技术导言
淘宝双11、京东618，大家疯狂抢购各种降价商品，不断确认提交订单，商家不断地发出快递；使用今日头条，无数你感兴趣的内容出现在你的面前，让你能够实时掌握你最关心的消息；使用滴滴，你快速又便宜地打到了车，到达了目的地；使用大众点评，你迅速找到了周围最受欢迎的饭店，吃到了可口的饭菜；使用中华万年历，你实时快速地知道了明天的天气预报，是否是黄道吉日，做好了一天的日程规划，诸如此类。日常生活中这些APP给大家的生活带来了翻天覆地的改变，老百姓的衣食住行也越来越依赖于这些APP。在这些或绚丽或实用的APP后面到底是什么技术在支撑着它们的运行呢？
从大的范围来讲，支撑这些APP的主要有前端、后端这两种技术。前端指的是用户能够直接感知到的那些东西，包括Web前端和客户端技术；而后端技术是相对于前端技术而言的，是藏在网络后面支撑网页、APP、应用软件运行的设施、环境、服务等。通过这两种技术的结合，就产生了一个稳定的互联网软件，可以给用户提供持续稳定的服务。其中后端技术通过几台甚至成千上万台服务器给前端提供高质量的服务，扮演了一个基础设施、运转轴心的角色。
相比前端技术的种类繁多以及不可预测性（比如诺基亚的Symbian在火爆了n年以后瞬间没落，相应的编程技术也随着失去了用武之地），后端技术还是比较稳定的，即使新的技术层出不穷，旧的应用比较广泛的技术也不会突然就走下历史舞台。但是后端技术的涵盖范围实在太广，Web、大数据、高并发、数据库、数据挖掘、机器学习……任何一个技能点单拎出来都需要花费极大的精力才能做到融会贯通。因此这并非一个人能够全部掌握的，即使是很多所谓的全栈工程师，其实也就掌握了系统前后端的基本技能而已，要说做到精通，则没几个人敢妄言。
由于前端技术和后端技术与用户接触的层次不一样，很多关注点也是不一样的。对于后端技术来讲，一般情况下需要关注的是以下几个指标。
● 可用率：能够提供正常服务的时间占线上运行时间的百分比。这是后端服务中一个很关键的指标，很多应用都需要达到99.9%以上。这里需要注意的是，系统的可用性经常是用响应时间作为衡量指标的，关注的是系统提供正常服务的效率；与响应时间类似，吞吐量是衡量系统可用性的另一个指标，指的是系统一段时间内的处理能力。
●稳定性：也叫作鲁棒性、健壮性，即服务在异常和危险情况下保持稳定的能力。
●容错性：在服务出现错误或者异常的时候，能够继续提供一定服务的能力，主要强调的是容许误差、故障的能力。
●扩展性：主要指服务的动态扩展能力，即通过扩展（而非修改）现有系统的能力来满足需求的能力。
●可维护性：指的是修正服务错误、修改服务功能的能力。
●安全性：保障系统以及用户数据安全的能力，包括保障系统不被非法入侵、用户数据不被泄露等。
除此之外很多书籍和资料上还会有可靠性、可用性等说法，其本质上是以上指标的另一种说法而已。一般来说后端服务只要满足了高可用、可容错、可扩展、可维护、稳定性、安全性即可。后端技术也基本是围绕着这几个目标来进行的。
综上，由于后端技术覆盖范围太广以及本人知识所限，本书所说的后端技术主要指一些Java后端工程师能够胜任开发工作应该必备的一些技能。1.1 后端基础设施
使用Java后端技术的目的就是构建业务应用，为用户提供在线或者离线服务。因此，一个业务应用需要哪些技术、依赖哪些基础设施就决定了需要掌握的后端技术有哪些。纵观整个互联网技术体系再结合公司的目前状况，笔者认为必不可少或者非常关键的后端基础技术/设施如图1-1所示。
这里的后端基础设施主要指的是应用软件在线上稳定运行需要依赖的关键组件或者服务。开发或者搭建好以上的后端基础设施，一般情况下是能够支撑很长一段时间内的业务的。此外，对于一个完整的架构来说，还有很多应用感知不到的系统基础服务，如负载均衡、自动化部署、系统安全等，并没有包含在本章的描述范围内。图1-11.1.1 请求统一入口——API网关
在移动APP的开发过程中，通常后端提供的接口需要以下功能的支持。
●负载均衡。
●API访问权限控制。
●用户鉴权。
一般的做法是，使用Nginx做负载均衡，然后在每个业务应用里做API接口的访问权限控制和用户鉴权，更优化一点的方式则是把后两者做成公共类库供所有业务调用。但从总体上看，这3种特性都属于业务的公共需求，更可取的方式则是集成到一起作为一个服务，这样既可以动态地修改权限控制和鉴权机制，也可以减少每个业务集成这些机制的成本。这种服务就是API网关，可以选择自己实现，也可以使用开源软件实现，如Kong。一般API网关的架构如图1-2所示。图1-2
但是以上方案的一个问题是，由于所有API请求都要经过网关，它很容易成为系统的性能瓶颈。因此，可以采取的方案是去掉API网关，让业务应用直接对接统一认证中心，在基础框架层面保证每个API调用都需要先通过统一认证中心的认证，这里可以采取缓存认证结果的方式避免对统一认证中心产生过大的请求压力。1.1.2 业务应用和后端基础框架
业务应用分为在线业务应用和内部业务应用，分别介绍如下。
●在线业务应用：直接面向互联网用户的应用、接口等，典型的特点就是请求量大、高并发、对故障的容忍度低。
●内部业务应用：主要面向公司内部用户的应用。比如，内部数据管理平台、广告投放平台等。相比在线业务应用，其特点是数据保密性高、压力小、并发量小、允许故障的发生。
业务应用是基于后端的基础框架进行开发的，针对Java后端来说，有以下几个框架。
●MVC框架：是统一开发流程、提高开发效率、屏蔽一些关键细节的Web/后端框架。典型的MVC框架如Spring MVC、Jersey、国人开发的JFinal以及阿里的WebX。
●IoC框架：可实现依赖注入/控制反转的框架。Java中最流行的Spring框架的核心就是IoC功能。
●ORM框架：是能够屏蔽底层数据库细节、提供统一的数据访问接口的数据库操作框架，另外也能够支持客户端主从、分库、分表等分布式特性。MyBatis是目前最流行的ORM框架。此外，Spring ORM中提供的JdbcTemplate也很不错。当然，对于分库分表、主从分离这些需求，一般需要自己实现，开源的则有阿里的TDDL、当当的Sharding-JDBC（从DataSource层面解决了分库分表、读/写分离的问题，对应用透明、零侵入）。此外，为了在服务层面统一解决分库分表、读/写分离、主备切换、缓存、故障恢复等问题，很多公司都开发了自己的数据库中间件，比如阿里的Cobar、360的Atlas、网易的DDB等；开源的则有MyCat和Kingshard，其中Kingshard已经有一定的线上使用规模。MySQL官方也提供了MySQL Proxy，可以使用Lua脚本自定义主从、读/写分离、分区这些逻辑，但其性能较差，目前使用较少。
●缓存框架：对Redis、Memcached这些缓存软件操作的统一封装，能够支持客户端分布式方案、主从等。一般使用Spring的RedisTemplate即可，也可以使用Jedis做自己的封装，支持客户端分布式方案、主从等。
●Java EE应用性能检测框架：对于线上的Java EE应用，需要有一个统一的框架集成到每一个业务中检测每一个请求、方法调用、JDBC连接、Redis连接等的耗时、状态等。Jwebap是一个可以使用的性能检测工具，但由于其已经很多年没有更新，有可能的话建议基于此项目做二次开发。
一般来说，以上几个框架即可完成一个后端应用的雏形。1.1.3 缓存、数据库、搜索引擎、消息队列
缓存、数据库、搜索引擎、消息队列这4者都是应用依赖的后端基础服务，它们的性能直接影响到应用的整体性能，有时候你代码写得再好也可能因为这些服务导致应用性能无法提升上去。
●缓存：缓存通常被用来解决热点数据的访问问题，是提高数据查询性能的强大武器。在高并发的后端应用中，将数据持久层的数据加载到缓存中，能够隔离高并发请求与后端数据库，避免数据库被大量请求击垮。目前除了内存中的本地缓存，比较普遍使用的缓存软件有Memcached和Redis，其中Redis已经成为最主流的缓存软件。
●数据库：数据库可以说是后端应用最基本的基础设施。基本上绝大多数业务数据都是持久化存储在数据库中的。主流的数据库包括传统的关系型数据库（MySQL、PostgreSQL）以及最近几年开始流行的NoSQL（MongoDB、HBase）。其中HBase是用于大数据领域的列数据库，受限于其查询性能，一般并不用于做业务数据库。
●搜索引擎：搜索引擎是针对全文检索以及数据各种维度查询设计的软件。目前用得比较多的开源软件是Solr和Elasticsearch，它们都是基于Lucene来实现的，不同之处主要在于Term Index的存储、分布式架构的支持等。Elasticsearch由于对集群的良好支持以及高性能的实现，已经逐渐成为搜索引擎的主流开源方案。
●消息队列：数据传输的一种方式就是通过消息队列。目前用得比较普遍的消息队列包括为日志设计的Kafka以及重事务的RabbitMQ等。在对消息丢失不是特别敏感且并不要求消息事务的场景下，选择Kafka能够获得更高的性能；否则，RabbitMQ则是更好的选择。1.1.4 文件存储
不管是业务应用、依赖的后端服务还是其他的各种服务，最终都要依赖于底层文件存储。通常来说，文件存储需要满足的特性有：可靠性、容灾性、稳定性，既要保证存储的数据不轻易丢失，即使发生故障也能够有回滚方案，也要保证高可用。在底层可以采用传统的RAID作为解决方案，再上一层，目前Hadoop的HDFS则是最普遍的分布式文件存储方案，当然还有NFS、Samba这种共享文件系统也提供了简单的分布式存储的特性。
此外，如果文件存储确实成为了应用的瓶颈，或者必须提高文件存储的性能从而提升整个系统的性能，那么最直接和简单的做法就是抛弃传统机械硬盘，用SSD硬盘替代。像现在很多公司在解决业务性能问题的时候，最终的关键点往往就是SSD。这也是用钱换取时间和人力成本最直接和最有效的方式。在数据库部分描述的SSDB，就是对LevelDB封装之后，利用SSD硬盘特性的一种高性能KV数据库。
至于HDFS，如果要使用上面的数据，需要通过Hadoop来实现。类似XX on YARN的一些技术就是将非Hadoop技术跑在HDFS上的解决方案。1.1.5 统一认证中心
统一认证中心，主要是对APP用户、内部用户、APP等的认证服务，包括
●用户的注册、登录验证、Token鉴权。
●内部信息系统用户的管理和登录鉴权。
●APP的管理，包括APP的secret生成、APP信息的验证（如验证接口签名）等。
之所以需要统一认证中心，就是为了能够集中对所有APP都会用到的信息进行管理，也给所有应用提供统一的认证服务。尤其是在有很多业务需要共享用户数据的时候，构建一个统一认证中心是非常必要的。此外，通过统一认证中心构建移动APP的单点登录也是水到渠成的事情：模仿Web的机制，将认证后的信息加密存储到本地存储中，供多个APP使用。1.1.6 单点登录系统
目前很多大的在线Web网站都是有单点登录系统的，通俗地说，就是只需要一次用户登录，就能够进入多个业务应用（权限可以不相同），非常方便用户操作。而在移动互联网公司中，内部的各种管理、信息系统，甚至外部应用同样也需要单点登录系统。
目前，比较成熟的、用得最多的单点登录系统应该是耶鲁大学开源的CAS，可以基于https：//github.com/apereo/cas/tree/master/cas-server-webapp来定制开发。
基本上，单点登录的原理都类似于图1-3。图1-31.1.7 统一配置中心
在Java后端应用中，一种读/写配置比较通用的方式就是将配置文件写在Propeties、YAML、HCON等文件中，修改的时候只需要更新文件重新部署，可以做到不牵扯代码层面改动的目的。统一配置中心，则是基于这种方式之上的统一对所有业务或者基础后端服务的相关配置文件进行管理的服务，具有以下特性。
●能够在线动态修改配置文件并生效。
●配置文件可以区分环境（开发、测试、生产等）。
●在Java中可以通过注解、XML配置的方式引入相关配置。
百度开源的Disconf是一个可以在生产环境中使用的方案，也可以根据自己的需求开发自己的配置中心，一般选择ZooKeeper作为配置存储。1.1.8 服务治理框架
对于外部API调用或者客户端对后端API的访问，可以使用HTTP协议或者RESTful （当然也可以直接通过最原始的Socket来调用）。但对于内部服务间的调用，一般都是通过RPC机制来进行的。目前主流的RPC协议有：
●RMI.
●Hessian.
●Thrift.
●Dubbo.
这些RPC协议各有优缺点，需要针对业务需求做出最好的选择。
这样，当你的系统服务逐渐增多，RPC调用链越来越复杂时，很多情况下需要不停地更新文档来维护这些调用关系。一个对这些服务进行管理的框架可以大大减少因此带来的烦琐的人力工作。
传统的ESB（企业服务总线）本质上就是一个服务治理方案，但ESB作为一种Proxy的角色存在于Client和Server之间，所有请求都需要经过ESB，这使得ESB很容易成为性能瓶颈。因此，基于传统的ESB，更好的一种设计如图1-4所示。
图1-4中以配置中心为枢纽，调用关系只存在于Client和提供服务的Server之间，这就避免了传统ESB的性能瓶颈问题。对于这种设计，ESB应该支持的特性如下。
●服务提供方的注册、管理。
●服务消费者的注册、管理。
●服务的版本管理、负载均衡、流量控制、服务降级、资源隔离。
●服务的容错、熔断。图1-4
阿里开源的Dubbo则对以上方案做了很好的实现，也是目前很多公司都在使用的方案；当当网的扩展项目Dubbox则在Dubbo之上加入了一些新特性。1.1.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则在基础的分布式调度之上又加入了弹性资源利用等更强大的功能。1.1.10 统一日志服务
日志是开发过程必不可少的东西。打印日志的时机、技巧很能体现出工程师编码水平。毕竟，日志是线上服务能够定位、排查异常最直接的来源。
通常，将日志分散在各个业务中非常不方便对问题的管理和排查。统一日志服务则使用单独的日志服务器记录日志，各个业务通过统一的日志框架将日志输出到日志服务器上。
可以通过实现Log4j或者LogBack的appender来实现统一日志框架，然后通过RPC调用将日志打印到日志服务器上。1.1.11 数据基础设施
数据是最近几年非常火的一个领域。从《精益数据分析》到《增长黑客》，都是在强调数据的非凡作用。很多公司也都在通过数据推动产品设计、市场运营、研发等。这里需要说明的一点是，只有当你的数据规模真的到了单机无法处理的规模时才应该上大数据相关技术，千万不要为了大数据而大数据。很多情况下使用单机程序+MySQL就能解决的问题，如盲目地上Hadoop则会既浪费时间又浪费人力。
这里需要补充一点的是，对于很多公司，尤其是离线业务没有那么密集的公司，在很多情况下大数据集群的资源是被浪费的。因此诞生了XX on YARN 一系列技术，让非Hadoop系的技术可以利用大数据集群的资源，这样能够大大提高资源的利用率，如Docker on YARN。
数据高速公路
对于上面介绍的统一日志服务，其输出的日志最终会变成数据，到数据高速公路上供后续的数据处理程序消费。这中间的过程包括日志的收集和传输。
●收集：统一日志服务将日志打印在日志服务上之后，需要日志收集机制将其集中起来。目前，常见的日志收集方案有Scribe、Chukwa、Kakfa和Flume。几种日志收集方案对比如表1-1所示。表1-1
此外，Logstash也是一个可以选择的日志收集方案，不同于以上几种方案的是，它更倾向于数据的预处理，且配置简单、清晰，经常以ELK（Elasticsearch+Logstash+Kibana）的架构用于运维场景中。
· 传输：通过消息队列将数据传输到数据处理服务中。对于日志来说，通常选择Kafka这个消息队列即可。
此外，这里还有一个关键之处，就是数据库和数据仓库间的数据同步问题，要有将需要分析的数据从数据库同步到诸如Hive这种数据仓库时使用的方案。可以使用Apache Sqoop进行基于时间戳的数据同步，此外，阿里开源的Canal实现了基于Binlog的增量同步，更加适合通用的同步场景，但是基于Canal还需要做不少的业务开发工作。
离线数据分析
离线数据分析是可以有延迟的，一般针对的是非实时需求的数据分析工作，产生的也是延迟1天的报表。目前最常用的离线数据分析技术除了Hadoop还有Spark。相比Hadoop，Spark在性能上有很大优势，当然对硬件资源要求也高。
对于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是多维数据实时分析的常用方案。对于其中常用的3个框架，对比如表1-2所示。表1-2
其中，Druid相对比较轻量，用的人较多，比较成熟。
数据即席分析
离线和实时数据分析产生的一些报表是给数据分析师、产品经理参考使用的，但是在很多情况下，线上的程序并不能满足这些需求方的需求。这时候就需要需求方自己对数据仓库进行查询统计。针对这些需求方，SQL上手容易、易描述等特点决定了其可能是最合适的方式。因此提供一个SQL的即席查询工具能够大大提高数据分析师、产品经理的工作效率，如Presto、Impala、Hive等都是这种工具。如果想进一步提供给需求方更加直观的UI操作界面，可以搭建内部的HUE，如图1-5所示。图1-51.1.12 故障监控
对于面向用户的线上服务，发生故障是一件很严重的事情。因此，做好线上服务的故障检测告警是一件非常重要的事情。可以将故障监控分为以下两个层面的监控。
●系统监控：主要指对主机的带宽、CPU、内存、硬盘、I/O等硬件资源的监控。可以使用Nagios、Cacti等开源软件进行监控。目前，市面上也有很多第三方服务能够提供对于主机资源的监控，如监控宝等。对于分布式服务集群（如Hadoop、Storm、Kafka、Flume等集群）的监控则可以使用Ganglia。此外，小米开源的OpenFalcon也很不错，涵盖了系统监控、JVM监控、应用监控等，也支持自定义的监控机制。
●业务监控：是在主机资源层面以上的监控，比如APP的PV、UV数据异常，交易失败等。需要业务中加入相关的监控代码，比如在异常抛出的地方加一段日志记录。
监控还有一个关键的步骤就是告警。告警的方式有很多种：邮件、IM、短信等。考虑到故障的重要性差异、告警的合理性、便于定位问题等因素，有以下建议。
●告警日志要记录发生故障的机器ID，尤其是在集群服务中，如果没有记录机器ID，那么对于后续的问题定位会很困难。
●要对告警做聚合，不要每一个故障都单独进行告警，这样会对工程师造成极大的困扰。
●要对告警做等级划分，不能对所有告警都做同样的优先级处理。
●使用微信作为告警软件，能够在节省短信成本的情况下，保证告警的到达率。
故障告警之后，最关键的就是应对了。对于创业公司来说，24小时待命是必备的素质，当遇到告警的时候，需要尽快对故障做出反应，找到问题所在，并能在可控时间内解决问题。对于故障问题的排查，基本上都是依赖于日志的。只要日志设置合理，一般情况下能够很快定位到问题所在，但是如果是分布式服务，并且在日志数据量特别大的情况下，如何定位日志就成为了难题。下面有两个方案。
●建立ELK（Elasticsearch+Logstash+Kibana）日志集中分析平台，便于快速搜索、定位日志。
●建立分布式请求追踪系统（也可以叫全链路监测系统）。对于分布式系统尤其是微服务架构，能够极方便地在海量调用中快速定位并收集单个异常请求信息，也能快速定位一条请求链路的性能瓶颈。唯品会的Mercury、阿里的鹰眼、新浪的WatchMan、Twitter开源的Zipkin基本都是基于Google的Dapper论文而来的。此外，Apache正在孵化中的HTrace则是针对大的分布式系统，诸如HDFS文件系统、HBase存储引擎而设计的分布式追踪方案。这里需要提到的一点是，如果你的微服务实现使用了Spring Cloud，那么Spring Cloud Sleuth则是最佳的分布式追踪方案。1.2 Java后端技术概览
基于1.1节介绍的后端基础设施，可以从中引出其需要的技能列表。进一步细化可以得到更为具体的技能树，也是Java后端工程师技能树的一个总体概览图（见本书下载资源）。
本书知识点围绕此技能树进行展开。1.2.1 软件开发的核心原则
此处所说的是软件开发应该遵循的一些核心原则。
●Don′t Repeat Yourself：这是软件开发的一个基础原则，即不要做重复性劳动，也是现在所说的“极客文化”的一种。代码重复、工作重复在软件开发中都是不合理的存在，利用各种手段消除这些重复是软件开发的一个核心工作准则。
●Keep it simple stupid：即KISS原则。在做软件设计的工作中，很多时候都不要想得过于复杂，也不要过度设计和过早优化，用最简单且行之有效的方案也就避免了复杂方案带来的各种额外成本。这样既有利于后续的维护，也有利于进一步的扩展。
●You Ain′t Gonna Need It：即YAGNI原则。只需要将应用程序必需的功能包含进来，而不要试图添加任何其他你认为可能需要的功能。因为在一个软件中，往往80%的请求都花费在20%的功能上。
●Done is better than perfect：在面对一个开发任务时，最佳的思路就是先把东西做出来，再去迭代优化。如果一开始就面面俱到，考虑到各种细节，那么很容易钻牛角尖而延误项目进度。
●Choose the most suitable things：这是在做方案选择、技术选型时候的一个很重要的原则。在面对许多技术方案、开源实现的时候，务必做到不能盲目求新，要选择最合适的而非被吹得天花乱坠的。1.2.2 软件开发的过程管理
在一个软件的生命周期中，除了开发还有其他步骤，也都需要掌握一些技术，分别介绍如下。
●项目管理：项目管理对于一个软件的开发是非常重要的，能够保证项目进度有条不紊地进行，在可控的时间内以一定的质量交付。瀑布开发模型、螺旋开发模型是传统的项目管理模型。在互联网的开发工作中，敏捷开发则是比较受推崇的开发方式。所谓的敏捷开发即快速实现原型，然后快速迭代。Scrum是目前普遍流行的敏捷开发方式之一。
●测试驱动开发：在平时的开发过程中，目前比较流行也是行之有效的一种方式就是Test Driven Develop，即测试驱动开发。这种方式的核心就是编写单元测试。简单来讲，就是先完成某一个功能的单元测试用例，然后在逐步消除测试用例的编译错误的过程中完成功能的开发。
●持续集成：某一个软件功能完成开发之后，后续还有测试、预发布、部署等过程。整个过程被称为集成，而持续集成指的是无须人工干预即可不断地进行这个过程。Jenkins、Quick Build都是比较典型的持续集成工具。1.2.3 日常开发常用工具
日常开发指的是一些日常需要掌握的技能、工具等，分别介绍如下。
●编辑器：开发中现在用得比较多的编辑器包括Emacs、Vim和SublimeText。笔者用得最多的就是SublimeText，基本能够满足自己的开发需求，包括编写脚本代码、查看代码文件等。Vim和Emacs这两款编辑器相对SublimeText来说需要记住很多命令，有一定的上手门槛。
●源码版本管理：代码的版本管理工具由CVS到SVN再到现在的Git，已经在事实上形成了以分布式版本管理为主的版本管理方案。基于Git，可以采用GitFlow作为源码管理模型。
●项目工具：GitHub是一个第三方Git中央仓库，是目前世界上最大的开源代码库，也能够作为私人的代码管理软件；Facebook开源的Phabrictor提供了非常强大的任务管理、Bug管理、测试、代码管理等，但其上手门槛相对较高；禅道是国人开发的一款项目管理工具，但是其免费版功能有限；以Tower.im为代表的第三方项目管理服务也是一个可以选择的方案，风险在于数据都不再是私有的。1.2.4 应用的运行环境
后端应用开发完成之后是需要部署到服务器上对外提供服务的。从最开始的直接在物理机上部署服务，到后来的虚拟环境、云环境，再到现在火热的容器，直至最近兴起的无服务器技术，都是为了让服务的运行环境能够更加便于建立、更容易维护、更容易扩展。
●Linux：说到后端服务器肯定绕不开Linux。至少现在互联网的后端服务绝大多数都是部署在Linux的各种服务器版本中的。其中CentOS、Ubuntu以及Debian是用得比较多的版本。对于Linux，需要熟练掌握的就是很多常用的Shell命令，如ps、netstat、lsof、ss、df、dh等。此外，很多性能分析命令，如top、vmstat、iostat、sar等，也需要熟练使用。
●应用服务器：就Java来讲，很多时候开发的都是Web应用，以HTTP协议对外提供服务。除了对性能要求比较苛刻的情况下需要自己构建HTTP服务外，大部分情况需要依赖于支持Java程序的应用服务器。目前最常用的有：Tomcat、Jetty。严格来讲，这两者只是Servlet容器，真正的Java EE应用服务器如JBoss、WebLogic在互联网领域很少使用。当然，这些软件并没有提供URL重写、请求委托等Web服务器功能，还不足以担当完整Web服务器的角色。Nginx则是目前最流行的Web服务器。
●负载均衡：在高并发流量环境下，后端服务会以集群的模式对外提供服务。在集群的前面，需要负载均衡器将请求分配到集群的各个节点上。LVS是最流行的四层负载均衡软件，HAProxy是另一个既支持四层又支持七层负载均衡的软件，Nginx则是七层负载均衡最流行的解决方案。当然，性能最好的负载均衡方案是以F5为代表的硬件负载均衡，但由于成本昂贵，在互联网团队中很少使用。此外，这里需要补充的是，为了保证同等角色的服务的高可用，如LVS经常作为流量的入口，会部署多个LVS节点互为主备，防止一个节点挂掉导致服务不可用。而实现互为主备的技术目前用得最多的就是Keepalived。
●虚拟化：虚拟化技术是前几年经常用来做私有云的一种技术，即将自己的物理主机通过虚拟化技术分裂为多个虚拟主机，以隔离资源。其中，VPS（虚拟专用服务器）的代表技术有微软的Virtual Server、VMware的ESX Server、SWsoft的Virtuozzo。此外，OpenStack提供的构建私有IIAS的功能、Cloud Foundry提供的构建私有平台运行环境以及Docker带来的容器服务，都是虚拟化技术的一种。1.2.5 常用第三方服务
虽然从根本上讲所有的软件服务都是可以自己开发或者部署到自己服务器上的，但是受限于成本、周期或者其他客观因素，很多服务需要第三方提供。
●IaaS：Infrastructure as a Service，是云计算最开始的一种模式，现在基本上所有的云服务商都提供IaaS服务。其中，全球最强大的云服务商是亚马逊的AWS，国内的则当属阿里云。就目前来看，即使是强如AWS也会出现一些运维故障，国内的这些云服务商的服务健壮性、运维响应更是经常被人吐糟。就笔者自己的经历来看，2010年左右，盛大云的云服务其实做得还不错，但后来由于种种原因市场份额越来越小。国内除了阿里云，UCloud也是一家专注做云计算的比较靠谱的公司。此外，还有一个青云，定位略显高端，也是不错的选择。当然，现在这些云服务商早就不仅仅是IaaS了，也提供了很多PaaS服务。
●PaaS：Platform as a Service，即只需要提交代码到指定的运行环境，其他的诸如代码打包、部署、IP绑定等都由平台完成。除了可以使用Cloud Foundry构建自己的PaaS平台以外，现在最流行的第三方PaaS服务有新浪的SAE、百度的BAE以及Google的GAE。
●域名：有一个可以提供服务的应用后，域名也是一个必需的基础设施。一个好的域名不仅代表了企业的形象，也能够更加方便用户的记忆与传播。目前购买域名可以通过国外的name.com、godaddy以及国内的万网等。有了域名之后下一步就得进行备案，域名提供商一般都提供了配套服务，或者找代理也可以办下来。此外，对于域名的解析，域名提供商一般会内置解析功能，也可以使用独立的DNS服务，如DNSPod。
●CDN：内容分发网络，即就近请求的一种技术实现。服务提供方将会被大量访问的内容在全国的多个节点都做缓存，这样当用户访问时就能够就近选择，从而减少网络传输延时，提高访问速度。国内目前七牛和又拍云都提供了不错的CDN服务，当然像阿里云、UCloud这种综合云服务商也都提供了CDN服务。
●邮件发送：这主要依赖邮件服务器，通过SMTP协议就可以实现发送。可以选择自己搭建邮件服务器，也可以选择使用腾讯邮箱、网易邮箱等。
●短信发送：使用短信发送验证码、营销短信是很常见的应用场景。由于短信是需要运营商支持的，所以基本上都需要依赖第三方代理。市面上有很多短信网关代理。
●消息推送：在移动应用上，推送已经成为一个标配功能。目前个推应该是第三方推送服务中的佼佼者，而且由于其客户很多，在联盟唤醒（一系列APP形成一个联盟，属于此联盟的APP中只要有一个被用户启动，就会静默唤起其他成员APP的后台进程。）上有很大的优势。
●开放平台：通过开放平台，可以使用OAuth等协议获取用户在第三方平台上的信息，以实现第三方平台登录等。目前，微博、微信、QQ是最常见的第三方登录方式，基本上都是使用OAuth协议为第三方开发者提供服务的。
●支付接口：支付接口是很多内置购买功能软件的必备组件。目前，接入最多的无非是支付宝和微信，二者都提供了开放平台供商家接入。当然，也有直接绑定银行卡支付的，此时需要走的就是银行或者银联的网关接口。1.2.6 计算机基础科学知识
像数据结构、算法、计算机网络、操作系统、计算机组成原理这些计算机科学基础知识，不管对于后端还是其他领域，都是必备的技能，也是所有软件开发的基础。扎实的计算机科学基础才能让你在学习、使用某种技术开发软件、调试软件、排查问题时心里有底、有据可循。
●数据结构：数据结构是组成程序的基础。经典的数据结构有字符串、数组、链表、哈希表、树（二叉树、平衡树、红黑树、B树）、堆栈、队列、图。
●算法：经典的排序和查找算法在平时的开发工作中经常会用到，如冒泡排序、插入排序、选择排序、归并排序、快速排序、希尔排序、堆排序以及二分查找等。此外，在函数/方法的算法实现中要注意递归和迭代各自的优缺点。而衡量算法性能的主要因素包含空间复杂度和时间复杂度。
●业务相关算法：除了上面的基本算法外，业务中还会经常涉及一些更复杂的算法，如压缩算法、LRU缓存算法、缓存一致性、编译原理中的状态机等。此外，目前越来越火的机器学习中也有很多算法，在很多业务场景中有很大的用途，如用于文本分词的结巴分词和中科院ICTCLAS，用于关键词提取的TF-IDF和TextRank，用于计算文本相似度的主题模型、Word2Vec、余弦相似度以及欧几里得距离，用
试读结束[说明：试读内容隐藏了图片]