浅析近十年来后端技术发展

工作十年，在大厂和创业公司都待过。做过广告、内容、SaaS、爬虫、搜索、推荐、大数据、在线教育等toG/to B/to C的产品，工作性质偏后端开发和管理相关，本文主要围绕后端开发技术这块，结合个人的经历，聊聊近十年来技术的发展变化，感受最深的是如下这3个方面：

1、微服务&三高架构发展成熟

近十年是移动互联网高速发展的十年，APP、小程序、公众号（营销）组合产品几乎成了每家公司的产品标配。而与之承接的后端，1vN，一般是统一的一套服务接口面向不同的端（当然可能会存在一些面向不同端的差异性开发）。与后端相关的技术架构——几乎无一例外都是重点围绕微服务 + 三高（高并发、高性能、高可用）架构，这种架构模式逐渐发展且趋向于成熟，目前基本的架构层次如图所示。

服务端：

语言上主要是java、php、python、go（排名不分先后，提一笔，不展开）

服务层除了业务微服务拆分，相应的技术框架支撑：

Spring家族（Spring、SpringBoot、SpringCloud)、Netty等通信框架、序列化/反序列化、ORM、K8S。

服务治理：服务注册、发现、负载均衡、配置管理、RPC通信、网关、限流、熔断、链路监控等。

第三方服务：短信、邮件、电话、PUSH、OBS等；大数据和机器学习的配合服务层使用，比如相关报告数据，机器学习模型服务（可以放到APP端上或服务端）

中间件：存储结构化 MySQL（读写分离、分库分表），非结构化存储诸如Redis、ES、MongoDB，消息队列Kafka、RabbitMQ、RocketMQ等，大数据存储Hbase等，这一层的服务目前也基本是采用云厂商提供的中间件服务。

基础层：现在更多是直接上云，采用云厂商提供的存储、ECS、容器化虚拟资源开箱即用。

对于三高要求的应对，也基本上暗藏在上述的组件运用中：

拆"微"服务、云化部署、弹性扩容、集群冗余；

缓存、消息异步解耦削峰、数据库分库分表、熔断限流降级；

配套大数据BI T+1/实时报表。

2、开发框架的发展成熟

首先基础开发框架这块

从Servlet+JSP，到SpringMVC，再到SpringBoot，SpringCloud开箱即用，约定大于配置，逐渐简化开发的配置以及相应的代码脚手架，快速支持项目生成。服务的分层基本上围绕Controller（API）+ Service + ORM DAO（mybatis/hibernate）来划分。没有对比就没有伤害，最初xml配置真是各种繁多，到后来注解、JavaConfig化，SpringBoot starter化，约定默认配置化，项目变得极其干净整洁。

其次是微服务化框架这块

2014年那会，我就开始接触微服务架构，当时结合业务拆成广告、订单、物料、账户、财务、报表等多个基础微服务，那时候的开发框架还是自己写，RPC，Zookeeper做服务注册发现，负载均衡，序列化/反序列化，动态代理，监控。至于网关限流这些还都没有像后来成熟的Gateway/kong、Hystrix、Sentinel等生态组件。

到后来在第二家公司的时候，当时dubbo开始兴起，主要支持服务注册、发现、RPC通信调用服务、序列化/反序列化、监控。公司内部结合dubbo完善了一套自己的框架体系，同时产出基础业务和基础技术服务，然后将整套解决方案和业务结合打造成平台向B端企业进行整体标准化/定制化SaaS输出。

再后来在一家公司，正值当时SpringCloud Netflix和SpringCloud Alibaba先后开始兴起。

Spring Cloud 是一套全家桶解决方案，包含若干个框架集合，包括 Spring Cloud config、Spring Cloud bus 等近 20 个子项目，提供了服务治理、服务网关、智能路由、负载均衡、熔断器、监控跟踪、分布式消息队列、配置管理等多个方面的解决方案。Spring Cloud 通过 Spring Boot 风格的封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留出一套简单易懂、容易部署的分布式系统开发工具包。不过其中组件过于繁多，维护代价大，不容易用好，而且部分组件后来维护支持不友好。过犹不及，如同一把瑞士军刀，如果不配合使用好，很容易伤到自己。

和Spring Cloud Netflix一样，Spring Cloud Alibaba也是一套微服务解决方案，于2019.7.24 Spring官方毕业。包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

主要组件有如下这些：

Apache Dubbo：一款高性能 Java RPC 框架。

Nacos：动态服务发现、配置管理和服务管理。

Sentinel：流量控制、熔断降级、系统负载保护服务的稳定性。

RocketMQ：一款开源的分布式消息系统。

Seata：微服务分布式事务解决方案。

这套解决方案，有大厂背书加持和落地实践检验，另外配套大厂的一些云服务和技术支持，几乎成为中小企业标配。

与此同时，另一种更加托管式的解决方案Service Mesh也风靡一时。这种解决方案是将这些基础的框架层的事剥离开来，并且统一下沉到基础设施层，主流的实现有Linkerd、Envoy、Istio。

这块本人接触不多，只是概念性了解，没有实践过，不展开细说。目前国内在生产环境中Service Mesh的落地案例似乎比较少。毕竟是用在生产，稳定性和可控性是第一要素，如果有大厂的落地实践和持续火热的技术圈支持，估计才会有大批的追随者。

再后来我在另一家公司，也采用的是微服务架构，其中的思想倒是和Service Mesh类似。当时的解决方案并没有选择基于Spring Cloud Netflix和Spring Cloud Alibaba（当时还没有毕业），而是选择基于k8s来做，即k8s + springboot2这种服务化框架。基于k8s做服务注册、发现（内部包含etcd）、负载均衡，基于Springboot2快速构建业务服务，服务之间基于HttpClient进行HTTP调用。结合Apollo进行配置管理，网关层没有采用Gateway，而是有一层对外业务API Controller层。监控报警，采用自研Agent搜集自己做的一套。（这套解决方案有一个细节问题就是服务的上线过程中会有新老服务发布不够平滑的问题，不过也被我们解决了。）

采用这套解决方案有这几个方面考虑：

一是尽可能简洁低成本化，微服务基础技术组件和业务开发剥离，降低业务开发团队成本。诸如k8s这块基本由运维团队承接维护，业务团队更多是配合进行k8s基础模板配置（比如探针，服务名等模板信息）。

二是公司服务开发有java和php两种语言体系，彼此都有服务之间的调用和交互，采用k8s这套相对比较成熟的服务托管式，基于http调用，能够无差别进行彼此通信衔接。而且是内网通信，通信耗时基本可以忽略。

三是k8s在大厂阿里/腾讯都有很好的云技术托管一站式服务。我先后都经历过在阿里云和腾讯云上采用这套解决方案，配合对应的大厂服务器资源虚拟化支持，部署非常方便快捷。另外，诸如服务监控，我们一开始是自己做的，后来在另外的项目里体会了下云厂商的监控接入方案，只要和对应的日志平台对接，采集，规则配置，看板、报警都是支持得很好。（付费接入）

当时采用的这套解决方案，有一个缺点就是服务治理比如熔断降级限流没有支持，后来也考虑接入阿里Sentinel进行服务熔断降级限流管控（调研过是能够无缝接入的）。这个在业务流量发展到一定阶段才按需接入、不做过度架构和设计，也是架构发展过程中很自然会应对的一种现象。

3、运维部署的便捷成熟

十年前，开发的部署更多的是纯物理机，到后来的虚拟化、容器化、云原生化。这方面大厂基本上做得很不错了，对创业公司而言也非常方便，开箱即用。这一点个人深有体会。

虽然我们是开发团队，不会直接做运维团队的事，但很多是互相配合支持的。你开发的东西要能够最终跑起来，部署到生产环境（上线），彼此相互配合是能够极大提高效率。

印象中公司有一个上线平台，把打好的war包，放到对应的公司内网物理开发机上，然后写好对应的上线命令（包括服务拉取上线包，文件替换，停服务，启动服务），让运维执行（后来开放给开发权限让开发去执行上线，devops雏形阶段）。正常情况下，运维只需要一键执行。但对于生手命令经常会弄错或没写全，另外这中间一些文件资源共享，都不是很方便，再到后来公司开始虚拟化Paas平台出现，资源的申请、部署都非常方便，直接从release平台拉取线上版本包，容器化部署。资源的扩容和申请等也都比之前好多了。

再后来去创业公司，运维部署这块更多是和阿里云、腾讯云打交道，总体感受还是很好的，当然这其中有一个重要原因是有一个好的公司运维团队中介。基本上是devops方式，jenkins部署推送上线到k8s，非常丝滑。云化部署维护、问题紧急修复上线，都非常便捷。（提一句，之前还经历过一个XX云，就不点名了，部署环境那叫一个头疼，做得挫就不说了，还坚持要用。另外你能感受到有和没有一个好的运维团队，真是一个天上一个地下，差得不是一点点）。

后记：

以上是web后端开发技术的发展变化，个人感受比较深的3个方面。当然这十年，技术的发展变化远不止上面这些，其他的诸如大数据技术、机器学习领域都发生很大的变化，这些希望随着后续接触的深入，再进行一些总结回顾。

技术的发展日新月异，给程序员这个行业的工作带来了压力和挑战，也带来了便捷和不断迭代突破的技术盛宴。

未来，仍在路上。继续保持对技术的热衷和敏感性，全面深入扩充技术矩阵。