全文请见《后端开发学习路径》

互联网行业发展至今，后端开发的职责早已不再是过去简单地围绕着数据库编排 CRUD（Create、Retrieve、Update、Delete）服务。很多时候，后端应用的第一行代码尚未写就，工程师便需要与产品、运营、法务等人员和网络、中间件、操作系统、数据、算法、运维、安全等技术体系打交道，互联网企业对工程师的要求越来越高。

单从技术栈来看，后端开发涉及编程语言、开发工具、开发框架、数据库与存储技术、中间件、操作系统、应用部署、运维监控等知识体系。

后端开发，编程是最基本的能力。目前，全球已经投入使用的编程语言超过 50 种，其中多数可用于后端开发，但术业有专攻，不同语言的流行度和学习成本不一样，各自的特性也有较大差异。在选择开发语言时，可以参考 国内大厂的主流编程语言。

工欲善其事，必先利其器。从事后端开发，选择称手的工具很重要。常用的开发工具包括集成开发环境、代码管理工具及建模工具。

集成开发环境（Integrated Development Environment，IDE）是指用于提供程序开发环境的应用程序，一般包括代码编辑器、编译器、调试器和图形用户界面等工具。集成了代码编写功能、分析功能、编译功能、调试功能等一体化的开发软件服务套件。所有具备这一特性的软件或者软件套（组）都可以叫集成开发环境。如微软的Visual Studio 系列，JetBrains 的 IDEs 系列等。IDE 可以独立运行，也可以和其他程序并用。在此推荐两种：

在实践中，一个软件项目通常由多名工程师协作完成，工程师各自开发自己所负责部分的同时，还需兼顾整个项目。由几个人协同开发的小项目尚可通过人力管理来应对，但几十人、几百人协作的项目呢？如果没有一个强大的工具支撑，那将无疑是人力“黑洞”，著名的版本控制软件 Git 便是在这种背景下诞生的。

为了提升设计环节的沟通效率，在较大的项目中，业界一般采用建模利器 Visual Paradigm 辅助。Visual Paradigm是一款UML建模工具，可以支持多种图表类型，比如：类图、用例图、序列图、状态机设计图、动态图、组件图、部署图、对象图、交互概述图、支持使用事件案例流、生成事件案例流序列图、需求管理、需求图、文本分析等。

框架是实现了某应用领域通用功能的底层服务。使用这种框架的软件开发者可以在通用功能已经实现的基础上开始具体的系统开发。框架提供了所有应用期望的默认行为的类集合。具体的应用通过重写子类或组装对象来支持应用专用的行为。通俗地说，框架是完成了某种应用的半成品，它可以提供一些常用的工具类和基础通用化的组件，基于此，软件开发者可以专注于自身业务的开发。

针对部分主流服务端编程语言，笔者在此列举对应的常用框架，如下表所示。

信息时代，数据已悄然成为企业的核心资产，由于数据库是数据唯一的持久层，几乎所有的业务流程最终都依赖数据库中的数据，因此作为后端开发工程师，掌握数据库及数据存储技术尤为重要。

数据库大致可以分为两大类，即 SQL 数据库和 NoSQL 数据库。SQL（Structured Query Language）数据库，指关系型数据库，主要代表有 SQL Server、Oracle、MySQL、PostgreSQL、SQLite。NoSQL（Not Only SQL）泛指非关系型数据库，主要代表有 MongoDB、Redis、HBase、Memcached。SQL、NoSQL数据库在存储数据类型和存储方式上差异较大。

关系型数据库适合存储结构化数据，如用户的账号、积分、等级、注册时间等。这些数据通常需要做结构化查询，比如过滤出所有积分大于 1000 的用户，使用 SQL 查询就非常方便，这类场景下，关系型数据库就要胜出一筹。

随着互联网的发展，海量数据场景越来越多，如发微博、发微信、发评论等。一方面，这些数据规模大，增长的速度难以预计；另一方面，这些数据类型比较复杂，可能同时包括文字、图片、音频、视频等，使用 SQL 无法直接存储。关系型数据库在应对这些场景时显得有些力不从心，逐渐暴露出许多难以克服的难题。因此出现了针对大规模数据场景，以性能卓越和应用便捷为目标的数据库产品——NOSQL 数据库。

NOSQL 数据库是主要根据 “非关系实体模型”的数据库，NOSQL的原意为 “Not only SQL”，而不是“NoSQL”，显然，NoSQL 数据库的出现并不是要完全否认或替代关系型数据库，只是做为传统关系型数据库的一个合理补充。

中间件（Middleware）是一种应用于分布式系统的基础软件。如图 1 所示，从纵向层次来看，中间件位于各类应用、服务与操作系统、数据库系统以及其他系统软件之间，主要解决分布式环境下数据传输、数据访问、应用调度、系统构建、系统集成和流程管理等问题。

目前，中间件并没有很严格的定义，但业界普遍接受 IDC 的定义：中间件是一种独立的系统软件服务程序，分布式应用软件借助这种软件在不同的技术之间共享资源，中间件位于服务器的操作系统之上，管理计算资源和网络通信。从这个意义上可以用一个等式来表示中间件：中间件=平台+通信，这也就限定了只有用于分布式系统中才能叫中间件，同时也把它与支撑软件和实用软件区分开来。

也称消息队列，是分布式系统中重要的组件，主要解决应用耦合、异步消息、流量削峰等问题。它可以实现高性能、高可用、可伸缩和最终一致性架构，是大型分布式系统不可缺少的中间件。消息队列在电商系统、消息通讯、日志收集等应用中扮演着关键作用，以阿里为例，其研发的消息队列（RocketMQ）在历次天猫“双十一”活动中支撑了万亿级的数据洪峰，为大规模交易提供了有力保障。

作为提升应用性能的重要手段，分布式消息队列技术在互联网领域得到了越来越广泛的关注 。常用的分布式消息队列开源软件有 Kafka、ActiveMQ、RabbitMQ 及 RocketMQ。

事务式中间件又称事务处理管理程序，是当前用得最广泛的中间件之一，主要用于解决分布式环境下的事务一致性问题。在单机数据库下很容易维持事务的 ACID（Atomicity、Consistency、Isolation、Durability）特性，但在分布式系统中并不容易，分布式事务中间件可以保证分布式系统中的分布式事务的 ACID 特性。

通常，分布式事务中间件可支持 DRDS、RDS、MySQL 等多种数据源，并兼容消息队列实现事务消息。通过各种组合，可以轻松实现分布式数据库事务、多库事务、消息事务、服务链路级事务等多种业务需求。常用的分布式事务中间有GTS、TXC、Seata等。

处于底层数据库和应用系统之间，主要用于屏蔽异构数据库的底层细节的中间件，是客户端与后台的数据库之间进行通信的桥梁。数据中间件一般用于解决海量请求下数据访问瓶颈及数据库的容灾问题，具备分布式数据库全生命周期的运维管控能力，支持分库分表、平滑扩容、结果集合并、SQL解析、数据库容灾和分布式事务等特性。开源的数据中间件有 Vitess、MyCat、Atlas、OneProxy等。

总体来看，目前开源的数据中间件比较少，广受认可的更是寥寥无几，大型互联网企业几乎都自研的数据中间件，如阿里的DRDS、蚂蚁的 Zdal、京东数科的 CDS、美团点评的 zebra 等等。

对于服务端研发工程师，学习并掌握操作系统知识极为重要。通常，服务端程序几乎都是部署在Linux操作系统的服务器上的。Linux 系统相关的知识点非常多，市面上介绍 Linux 系统的书籍基本都是“大部头”，通篇学习实属不易，效果也很难保证。对于服务端开发工程师，可重点学习一些常用的命令和操作：

工程师开发的代码需要经过编译、打包等流程，并最终部署到服务器上，才能运行并对外提供服务。在 2014 年前，生产环境应用部署一般是通过工程师编写脚本实现，而开发环境则基本是手动部署，效率普遍较低。经过多年的发展，目前在一些头部互联网企业，研发平台和流程已经非常完善，不仅可以支持不同研发环境下自动编译、部署，而且能提供场景化分析、定制化质量和风险控制能力。研发平台化、流程标准化使研发更加简单、高效、可靠的同时，也对工程师屏蔽了背后的技术细节，某种程度上对初入职场的服务端研发工程师是不利的，应用部署不应该成为一个“黑盒”。应用部署的发展历程，大致可分为物理机部署、虚拟机部署和容器化部署三个阶段。读者可重点了解容器化部署。

为了解决虚拟机部署的不足，容器技术应运而生。容器化部署的本质是构建一个完整、独立的运行环境，包含三个关键：环境隔离、资源控制和文件系统。Docker 便是容器化部署的佼佼者， 自2013年发布，目前已成为了首屈一指的容器平台。它能提供轻量的虚拟化和一致性环境，允许将应用和其依赖的运行环境打包在一起，打包好的“集装箱”（镜像）能够被分发到任何节点上执行，无需再进行配置环境的部署。如此一来就解决了开发和部署应用时环境配置的问题，规范了应用交付和部署，降低了部署测试的复杂度以及开发运维的耦合度，极大提升了容器移植的便利性，便于构建自动化的部署交付流程。

运维监控对应用稳定运行、业务效果感知十分重要。通过日常运维监控，一方面有助于预警、定位问题，从而快速解决，避免影响扩大化；另一方面，还可以洞悉业务效果和发展趋势，从而帮助业务决策。

在互联网企业，对于一个上线运行的产品，运维监控在其整个生命周期中将一直存在。当产品用户规模较小或业务场景较少时，运维监控通常由产品和研发兼任，甚至完全由研发负责；当产品的用户量增长到一定规模或业务场景增加时，运维监控通常会逐步独立出来由专职人员负责，通常称为 SRE（Site Reliability Engineer）。

在实践中，如何开展运维监控呢？基础监控（CPU、Load、硬盘、内存、网络等），一般可借助专业的监控工具（如Anturis、SeaLion、Icinga、Munin 等），并非服务端研发工程师专长。事实上，对于服务端研发，最重要的依托是日志，如图 2 所示，基于规范的日志可以快速构建、感知常用服务指标。站在业务角度，合理打印日志不仅能辅助定位问题原因，同时可以多维度聚合分析各类场景。某种程度上，排查问题的过程，其本质就是日志结构化还原的过程。如果日志能结构化还原特定场景，那么该场景就能快速被定位。