后端技术趋势指南：如何选择自己的技术方向
The following article is from 极客重生 Author Alex码农的艺术
编程多条路，条条通罗马
后台大佬
后台路线都是面对后台服务器业务，比如web后台服务器，视频后台服务器，搜索后台服务器，游戏后台服务器，直播后台服务器，社交IM后台服务器等等，大部分代码和业务逻辑相关，想成为大佬，必须精通专业领域业务知识。
但同时也存在一些通用的技术要求, 比如熟悉编程语言，数据结构与算法， 网络编程，TCP/IP协议，数据库，中间件，高性能，高可用技术。
后台技术演进
架构演进
随着 PC 局域网，特别是关系型数据库的应用，基础架构发展成了两层架构；随后是广域网的发展，由单体的多层架构，出现了 SOA，EDA 架构盛行；接下来是虚拟机，再到今天的云计算基础架构，又出现了微服务，之后是 Container as a Service、Serverless ，到最近很火原云生架构等，可以看到架构的变化都是要充分利用 IT 基础设施。
业务目标演进
以往互联网流量爆发时代，先抗住流量峰值，高并发、高性能是，支持水平扩展是后台设计的重要目标 。当前互联网流量见顶，存量竞争加剧，后台服务的稳定性变得愈发重要，企业降本增效决心变强，研发效率，监控运维平台，自动化测试，CI/CD流水线等也变得重要起来。
后台开发语言演进
服务器硬件资源昂贵年代，C++既能高性能，又能代码复用（OOP编程），成了很多大厂后台开发的主力语言。
第一代web后台开发主流是PHP，那时候互联网主流的后台架构是LAMP架构，随着电商兴起，Android 手机普及，大数据出现，推动JAVA技术栈发展，JAVA成了互联网主流后台编程语言。
随着云计算时代到来，云原生计算兴起，Go语言生态发展稳健，兼顾性能和开发速度，越来越多企业在生产中使用 Go语言落地业务，目前很多大厂后台开发语言已经开始转向Go。
人工智能发展，也推动Python语言发展，简单，上手快，开发效率高，成了一些不在乎性能后台组件的开发语言。
由于安全性，稳定性越发重要，Rust有可能成后台关键组件开发语言，兼顾性能和内存安全性，用来替换后台系统核心的C++组件；
对于未来，Python、Go、Rust 成为后端未来最先考虑学习编程语言。
目前国内各个大厂主流后台语言不尽相同：
腾讯偏向C++，Go等，Go越来越流行
阿里，拼多多，美团，京东偏向Java
字节偏向Go/Python
百度偏向C++
华为偏向C/C++
中间件高手
中间件（Middleware）一种应用于分布式系统的基础软件，自上世纪80年代诞生以来，在分布式环境中低调地发挥着重要作用。基于中间件，系统软件与应用软件之间实现了高效连接与沟通，应用开发得以提速。
消息中间件
ActiveMQ 的社区算是比较成熟，但是较目前来说，ActiveMQ 的性能比较差，而且版本迭代很慢，不推荐使用。
RabbitMQ 在吞吐量方面虽然稍逊于 Kafka 和 RocketMQ ，但是由于它基于 erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。但是也因为 RabbitMQ 基于 erlang 开发，所以国内很少有公司有实力做erlang源码级别的研究和定制。如果业务场景对并发量要求不是太高（十万级、百万级），那这四种消息队列中，RabbitMQ 一定是你的首选。如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。
RocketMQ 阿里出品，Java 系开源项目，源代码我们可以直接阅读，然后可以定制自己公司的MQ，并且 RocketMQ 有阿里巴巴的实际业务场景的实战考验。RocketMQ 社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些。还有就是阿里出台的技术，你得应对这个技术万一被抛弃，社区黄掉的风险，如果你们公司有技术实力我觉得用RocketMQ 挺好的。
Kafka 的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms 级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展。同时 Kafka 最好是支撑较少的 topic 数量即可，保证其超高吞吐量。Kafka 唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略。Kafka天然适合大数据实时计算以及日志收集。
下一代消息中间件Apache Pulsar：
对比kafka
Apache Pulsar 和 Apache Kafka 之间的根本区别在于 Apache Kafka 是以分区为存储中心，而 Apache Pulsar 是以 Segment 为存储中心, Apache Pulsar 这种独特的基于分布式日志存储的以 Segment 为中心的发布/订阅消息系统可以提供许多优势，例如可靠的流式系统，包括无限制的日志存储，无需分区重新平衡的即时扩展，快速复制修复以及通过最大化数据放置实现高写入和读取可用性选项.
缓存中间件
我们都知道CPU的缓存的作用是为了减少对内存访问，同样扩展到分布式系统里面，缓存中间件可以提高对组件数据的访问性能。
redis就是比较流行缓存中间件，根据局部性原理，冷热数据分离，一般用来加快数据库的高频数据访问：
未来优化方向：
高可用
持久化优化
安全加密
IO、连接优化
多线程优化
数据结构优化，支持更多数据结构
RPC框架
RPC是指远程过程调用，也就是说两台服务器A，B，一个应用部署在A服务器上，想要调用B服务器上应用提供的函数/方法，由于不在一个内存空间，不能直接调用，需要通过网络来表达调用的语义和传达调用的数据。
微服务时代的远程服务调用框架。如grpc, Thrift, 阿里的 HSF, Dubbo, SOFA-RPC；
未来发展方向：
支持微服务技术演进
框架侵入性改进，语言无关，通信协议无关。
Service Mesh，Service Mesh是一个基础设施层，其独立运行在应用服务之外，提供应用服务之间安全、可靠、高效的通信，并为服务通信实现了微服务运行所需的基本组件功能，包括服务注册发现、负载均衡、故障恢复、监控、权限控制等等
性能优化，序列化协议优化，消息编码优化，网络IO优化等。
负载均衡
负载均衡（Load Balancing）是高可用网络基础架构的关键组件，通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性
硬件：F5、Redware...
软件：lvs（四层）、haproxy（四，七层）、nginx（七层）...
未来发展方向：
支持更智能调度算法：
循环 - 请求按顺序分布在服务器组中。
最少的连接 ——一个新的请求被发送到与客户端的当前连接最少的服务器。每个服务器的相对计算能力被考虑到确定哪个服务器的连接最少。
最短时间- 将请求发送到由结合了
最快响应时间和最少活动连接的公式选择的服务器。NGINX Plus 独有。Hash – 根据您定义的密钥分发请求，例如客户端 IP 地址或
请求 URL。
如果上游服务器集发生变化，NGINX Plus 可以选择应用一致的哈希来最小化负载的重新分配。IP Hash – 客户端的 IP 地址用于确定哪个服务器接收请求。
业务上云，云上负载均衡（LaaS，PaaS服务）。
高性能优化，降低成本，大流量（IO优化，DPDK，FPGA，P4演进），硬件。
高可用，可观测，监控统计，告警系统，平滑扩容，服务剔除，无状态化。
内核大师
内核路线，探究底层奥秘
云计算
云计算进程提速，一切皆服务，导致原来不挣钱底层技术，可以卖钱了，技术可以通过云计算向外输出，这是底层技术人春天的到来:
Software as a Service，软件即服务，简称SaaS，这层的作用是将应用作为服务提供给客户。
Platform as a Service，平台即服务，简称PaaS，这层的作用是将一个开发平台作为服务提供给用户。
Infrastructure as a Service， 基础设施即服务，简称IaaS，这层的作用是提供虚拟机或者其他资源作为服务提供给用户。
IaaS核心技术：计算，网络，存储，这些可以算是软件技术的最底层了（再底层，就是硬件了
计算：计算虚拟化，内核调度系统，cgroups，KVM, QEMU,virtio；
网络：网络虚拟化，内核协议栈，netfilter，netns，DPDK，智能网卡，RDMA，P4等；
存储：内存虚拟化，磁盘虚拟化,SPDK等；
PaaS核心技术：应用运行环境（容器，多租户弹性，K8S），应用全生命周期支持（devops，自动化运维），集成、复合应用构建能力（CI/CD）等。
这些技术职位本身门槛是很高的，待遇也比一般职位要高，对底层技术非常感兴趣可以关注。
浏览器内核
webkit
WebKit是Safari、Mail、App Store 和 macOS、iOS 和 Linux 上的许多其他应用程序使用的网络浏览器引擎。
Chromium
Chromium是一个用于网络浏览器的免费开源 代码库，主要由Google开发和维护。Google 使用该代码制作其Chrome网络浏览器，该浏览器具有附加功能。
Chromium代码库被广泛使用。Microsoft Edge、Opera，QQ浏览器，UC浏览器等国内浏览器，和许多其他浏览器都基于该代码。此外，代码的重要部分被多个应用程序框架使用。
chromium架构
C++是主要语言，约占代码库的一半。这包括Blink和V8 引擎、HTTP和其他协议的实现、内部缓存系统和其他基本浏览器组件。一些用户界面是用HTML、CSS和JavaScript 实现的。大量的网络平台测试也是用这些语言编写的。大约 10% 的代码库是用C编写的。这主要来自提供基本功能的第三方库，例如SQLite和众多编解码器。支持移动 操作系统需要特殊的语言：Java的用于Android的，和iOS的两个斯威夫特和Objective-C的。（Apple的WebKit引擎的副本也在代码库中，因为 iOS 浏览器需要它）
如果对web内核技术感兴趣，可以选择浏览器方向！
数据库内核
技术初衷
在操作系统出现之后，随着计算机应用范围的扩大、需要处理的数据迅速膨胀。最初，数据与程序一样，以简单的文件作为主要存储形式。以这种方式组织的数据在逻辑上更简单，但可扩展性差，访问这种数据的程序需要了解数据的具体组织格式。当系统数据量大或者用户访问量大时，应用程序还需要解决数据的完整性、一致性以及安全性等一系列的问题。因此，必须开发出一种系统软件，它应该能够像操作系统屏蔽了硬件访问复杂性那样，屏蔽数据访问的复杂性。由此产生了数据管理系统，即数据库。
目前现状
世界范围内，做数据库开发的，基本上都是基于开源项目，即便是自研也肯定会参考现有的开源项目，所以要选择数据库，必须要把开源玩的非常溜才行，比如MySQL, PostgreSQL, MongoDB, LevelDB等。目前云计算厂商都在大力发展数据库，在国内公有云部署模式中，阿里、腾讯、AWS、Oracle、华为、Microsoft位列前六，于国内数据库行业而言，数据库厂商取得四十年最好的发展机会，市场大环境(国家去IOE化战略）有利于国内厂商，技术方面总体接近，一些技术持平甚至领先
当前热门方向：
分布式数据库，分片，事务，一致性等
数据库性能优化，SQL指令优化，软件优化，硬件加速
高可用架构
存量数据库上云
数据库智能化，自动化管控
云原生架构
如果对数据库技术感兴趣，可以选择这条路。
操作系统
目前国家大力发在新基建，鼓励和政策支持企业开发基础技术，操作系统当前就是一个重要方向，目前各大公司要么自研OS，要么基于开源OS进行二次开发。
目前热门技术方向：
鸿蒙开源OS，自研OS
嵌入式OS，自研和基于嵌入式Linux
手机OS，基于Android二次开发
云计算OS，基于Linux 内核, Redhat发行版等二次开发
开发OS，主要是适配新硬件，性能优化（调度性能，内存分配性能，协议栈处理性能，文件系统优化），稳定性优化，虚拟化技术等。
如果对OS有情怀，喜欢和底层硬件打交道，可以选择操作系统方向，目前前景还不错！
嵌入式
由于5G，AI发展，手机，智能硬件，自动驾驶，IoT领域又焕发新春，各种智能硬件起飞。
热门技术方向：
嵌入式OS（Vxworks,Alios, TencentOS tiny, Huawei LiteOS、RT-Thread等）
智能家居系统
手机OS（鸿蒙，Android等）
手机性能优化（性能和节能更强）
自动驾驶技术
喜欢硬件的发烧友，喜欢车库文化的极客，可以选择！
JDK
自1995年Sun公司推出Java至今，Java这门编程语言已经风光了25年。最近关于Java要没落的言论甚嚣尘上，但Java仍然是国内中国互联网公司首选的编程语言，诸如阿里巴巴、京东、百度、腾讯、美团等。随着互联网、大数据、AI的迅猛发展，国内JAVA生态已逐渐划分成了几大阵营，J2EE企业级应用传统领域是大厂商（甲骨文、微软）主导，互联网领域是pivotal，互联网中间件是阿里云和pivotal在推spring cloud，大数据、移动安卓又分别是另一个独立生态。
OpenJDK（开放 Java 开发工具包）是Java 平台标准版(Java SE)的免费开源实现。目前各个大公司都在发展自己JDK版本，如果想在Java领域深耕且想转为底层开发，可以选择JDK这条路！
分布式专家
微服务
Service Mesh 在过去的一年依旧保持着热度。在已经过去的 2020，微服务可以说有坚守也有破局，有对服务微化共识的形成也有对特殊场景的理性思考。我们可以看到服务框架依然在持续演进，奔向云原生，拥抱云化。越来越多的企业开始跟上服务化云化步伐。
微服务、DDD、中台技术并非企业技术架构设计的银弹，微服务的主要缺点是微服务的分布式特点带来的复杂性。开发人员需要基于RPC或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。
腾讯开源的微服务框架TARS：
但微服务仍然分布式的热门方向，符合高内聚，低耦合架构设计思想，这个过程中出现的问题等着我们去解决，比如Service Mesh出现。
Service Mesh作为Sidebar运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在Service Mesh中实现。
目前流行的Service Mesh开源软件有Linkerd、Envoy和Istio，而最近Buoyant（开源Linkerd的公司）又发布了基于Kubernetes的Service Mesh开源项目Conduit。
中台架构
当前企业做大做强后，业务必然会增多，开始出现重复造轮子，由于业务扩张，本身人力就不足，所以长期方案还是会采用类似中台的技术，这样节约人力，具体怎么落地，这个是考验团队和公司从上到下的推动能力了。
云原生
云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。
2021年伊始，云原生的布局开始加速。华为云联合CNCF（云原生计算基金会）、中国信通院成立创原会，加速云原生产业落地；金山云发布云原生全景图、云原生产品矩阵和最新的Serverless产品；诺基亚宣布与谷歌云合作开发云原生5G技术……几乎所有云厂商新发布的云计算产品都已打上了云原生的标签。
云原生核心技术：
容器化：作为应用包装的载体
持续交付：利用容器的轻便的特性，构建持续集成和持续发布的流水线
DevOps：开发与运维之间的协同，上升到一种文化的层次，能够让应用快速的部署和发布
微服务：这是应用开发的一种理念，将单体应用拆分为微服务才能更好的实现云原生，才能独立的部署、扩展和更新
K8S已经成为下一代云原生操作系统
Kubernetes 最初源于谷歌内部的 Borg，提供了面向应用的容器集群部署和管理系统。Kubernetes 的目标旨在消除编排物理 / 虚拟计算，网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。Kubernetes 也提供稳定、兼容的基础（平台），用于构建定制化的 workflows 和更高级的自动化任务。Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。Kubernetes 还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。
如果你想成为互联网架构师，K8S架构是你应该去了解的。
什么时候要考虑开始跳槽了
一般在一家公司，认真努力工作三年后（摸鱼不算），职位没有普升或者薪水没有翻倍，就可以考虑跳槽了，请记住我们的口号是：
如何应对技术趋势变化
软件设计有两个关键目标：高内聚、低耦合，围绕这2个核心目标，又提出了单一职责、开闭原则、里氏替换、依赖导致、接口隔离、最少知识等设计原则。
软件工程师一直都在为这两个目标而努力奋斗，以求把软件编写得更加清晰、更加健壮、更加易于扩展和维护。
但后来，人们发现有更多的诉求，希望开发软件变得更简单、更快捷，程序员希望更少编写代码，非专业人员也希望能开发程序，于是，更多的更傻瓜的编程语言被发明出来，更多的编程技术和编程思想被发明出来，比如库、组件、云基础设施。
于是很多技术变成了屠龙之技，比如汇编，时代变了，建国后动物不能成精了，没有龙可以宰了，然后很多软件工程师摇身一变成了调参工程师、Call API砖家、用库包能手、拼组件达人，这是效率分工的结果，也是技术发展的使然。
纵观近二十年的科技互联网发展历程，大的趋势是技术下沉，特别是近些年，随着云计算的发展和普及，基础设施越来越厚实，业务开发变得越来越容易，也越来越没有技术含量，而之前困扰小团队的性能、负载、安全性、扩展性问题都不复存在，这不禁让互联网行业的油腻大叔们噤若寒蝉，仿佛分分钟就要被卷入历史洪流而万劫不复。
虽然不可否认技术的重要性在降低，但也还不至于那么悲观。遥想PC时代，当VB、Delphi、MFC出现的时候，也有类似论调，所见即所得，点点鼠标，就可以开发PC桌面程序，是不是很高端？那时候码农的担心相比现在恐怕是只多不少吧，但后来随着互联网兴起，出现了后端开发这个工种，码农很快找到了新的战场，网络、分布式、数据库、海量服务、容灾防错，于是又玩出一堆新花样。
技术永远在不停向前发展，而我们需要加深对基础知识的理解，以不变应万变，深耕一个领域，同时也需要多去尝试新技术，扩宽自己的眼界，增加解决问题的思路，当你有一技之长后，即便国内35危机，你还可以去外企（Google，Facebook，亚马逊，微软等）养老
参考和扩展阅读
https://jimmysong.io/kubernetes-handbook/concepts/
https://cloud.51cto.com/art/202103/652294.htm
https://cloud.tencent.com/developer/article/1404117
https://www.zhihu.com/question/22799206
https://www.chromium.org/developers/design-documents/multi-process-architecture
https://blog.csdn.net/zxc024000/article/details/80157332
https://juejin.cn/post/6844904197859590151
- EOF -
推荐阅读 点击标题可跳转关注『CPP开发者』
看精选C++技术文章 . 加C++开发者专属圈子
点赞和在看就是最大的支持❤️