2021下半年有哪些不能错过的技术趋势？（上）
作者：腾讯在线教育技术团队
导语| 腾讯在线教育部后台中心团队，作为在线教育行业的从业者，尝试整理一下2020年后端技术要点，以此窥探后台未来技术的发展趋势：
①云计算进程提速，一切皆服务。
②云上安全越来越受到企业的重视。
③从资源云向业务云化转变，最终全面云原生化。
④微服务、DDD、中台技术并非企业技术架构设计的银弹。
⑤Python、Go、Rust成为后端未来最先考虑学习编程语言。
⑥Go语言生态发展稳健，越来越多企业在生产中使用Go语言落地业务。
⑦疫情催化在线教育行业产品升级转型，音视频技术不断迭代升级。
本文将对前四个趋势进行展开介绍。
01
云原生
1. 业内趋势
云原生技术生态日趋完善，细分项目不断涌现
云原生关键技术正在被广泛采纳，如43.9%的用户已在生产环境中采纳容器技术，超过七成的用户已经或计划使用微服务架构进行业务开发部署。
容器云平台将传统云计算的IaaS层和PaaS层融合
从技术角度看，容器云平台采用容器、容器编排、服务网格，无服务等技术构建的一种轻量化PaaS平台，为应用提供了开发、编排、发布、治理和运维等全生命周期管理。
容器云平台的整体架构，自下而上包括交互(UI)层、接口(API)层、PaaS服务层、基础层。运维和安全则涵盖了从应用层到容器云引擎层的部分：
- 交互层：提供界面供用户使用
- 接口层：提供OpenAPI能力供第三方调用
- PaaS服务层：提供数据服务、应用服务（微服务、中间件）、DevOps、平台管理、平台运营、应用管理能力，为实现业务应用其自身的生命周期管理
- 基础层：以Kubernetes为核心，包括服务网格（ServiceMesh）、无服务计算（Serverless）、容器引擎（Docker）、容器镜像管理等，主要实现对计算、网络和存储资源的池化管理，以及以Pod为核心的调度和管理。
服务网格为微服务带来新的变革
Mesh化加速业务逻辑与非业务逻辑的解耦，将非业务功能从客户端SDK中分离出来放入独立进程，利用Pod中容器共享资源的特性，实现用户无感知的治理接管。
从资源云向业务云化转变，最终全面云原生化
云原生技术通过标准化资源，轻量化弹性调度等特征，应用场景较为广泛，随着技术和生态不断成熟和完善，有效缓解企业上云顾虑，拉动全行业的上云程度。
云原生技术栈的标准统一化
架构标准统一（微服务之间标准API接口通信）、交付标准统一（标准容器化的打包方式实现真正的应用可移植）、研运过程标准统一（DevOps工具链标准统一），通过标准化后提升整体研发运维效能。
02
在线教育实践
各类PaaS服务上云
2019年我们完成了IaaS、存储层、直播、回放以及各类PaaS服务的上云。
服务全面容器化升级
2020年我们重点进行服务全面的容器化升级，目前已经完成企鹅辅导和开心鼠英语两个产品的全面改造，到年底会完成腾讯课堂剩余部分的升级，实现全面完成改造。
完善DevOps流程
完善CI/CD/CO、蓝盾流水线、容器化、STKE、全链路监控等，提高研发效率，降低现网运营难度
业务中台架构演进
在整体架构上，我们依托腾讯云，确定了教育业务中台的架构演进方向，不断的进行重复模块的抽象和整合。我们在腾讯云上实现部署了接入中台、Push中台、支付中台、音视频中台、运营中台等服务，让各个业务之间的相似能力得以复用。
存储层上云
存储层上云后，一方面稳定性提高。
- 异地容灾。通过挂载异地的灾备机器，可以实现master主机异地灾备。
- 负载均衡。服务连接RO组，RO组的多个实例会对请求进行负载均衡。
- 数据备份。RO发生异常，将会被剔除RO组，恢复后自动加入RO组，保证了RO组的可用性。
- 数据加密。提供透明数据加密（Transparent Data Encryption，TDE）功能，透明加密指数据的加解密操作对用户透明，支持对数据文件进行实时 I/O 加密和解密，在数据写入磁盘前进行加密，从磁盘读入内存时进行解密，可满足静态数据加密的合规性要求。
另一方面运营能力也有所提升。
- 可以实时看到数据库连接情况，慢查询、全表扫描、查询、更新、删除、插入情况
- 实时CPU、内存、磁盘使用情况，并根据设置阈值进行告警优化微服务架构
下面是在线教育上云前后架构对比
03
微服务
微服务,Service Mesh在过去的一年依旧保持着热度。在已经过去的2020，微服务可以说有坚守也有破局，有对服务微化共识的形成也有对特殊场景的理性思考。我们可以看到服务框架依然在持续演进，奔向云原生，拥抱云化。越来越多的企业开始跟上服务化云化步伐。
微服务框架：加速奔向云原生
SpringCloud
2018 年开始 Hystrix、Ribbon 等核心组件相继进入维护状态，开发者们一度变得忧心忡忡，时至今日我们回过头来再看一下，Spring Cloud 已经针对这些担忧给出了解决方案，Zuul由Spring Cloud GateWay 子项目替代，Hystrix由Spring Cloud Circuit Breaker替代，同时也给出了长期的演进方案。在经历了这段小小的波折后，Spring Cloud 也改变了策略，将这些企业贡献的OSS库独立出来成为其子项目。目前我们可以看到有Azure，Alibaba, Amazon 等3个带有企业名字的子项目，这种策略在某种程度上可以说解绑了企业开源策略对开源核心组件的影响。截至目前Spring Cloud下面的子项目已经新增至34个，越来越庞大。供开发者选择的组件越来越多。
Doubbo
2019年05月20日 Dubbo毕业，成为 Apache 的顶级项目，在过去的一年社区还是非常努力的，一年release 5个版本，加速奔向云原生。在2.7.5版本中，其服务模型调整以及协议支持调整带来的新旧版本兼容问题，稳定性等问题值得我们持续关注。
Istio
记得2019年我们一直在谈istio 版本难产问题，在2020 年却出乎意外的因为商标问题上了头条，让我们吃了个大瓜。Google 与 IBM 在商标问题上发生分歧，Istio 商标被 Google 捐献给 Open Usage Commons 组织，而非 CNCF。而这在加速了Service Mesh 阵营依旧的分化，各大软件厂商纷纷发布了自己的Service Mesh 产品，如微软发布了Open Service Mesh，Kong 推出了Kuma，Nginx也推出了NGINX Service Mesh（NSM）。
企业微服务建设：长期修行，苦练内功
在微服务框架的演进过程中我们看到都在朝着趋同的方向发展，主要聚焦于微服务治理形态上组件的差异化以及应对场景的方案细化，可能你们家服务中心用的ZK，我们家就自研。恰逢内源的兴起，似乎在企业内部再造一次轮子，研发一套特定的框架来适配企业业务以及标准化企业内部IT治理也是一件很容易的事情，基于这种写实的场景部分企业开始涌现出了内源的服务框架如，腾讯的tRPC框架。
腾讯tRPC建设情况
目前tRPC在腾讯内部已经大面积推广使用，覆盖5个BG，40+部门，2700+服务，10000+容器，支持c++,go,java,js,rust,python 6种编程语言。其可插拔的插件化架构，高性能，友好的架构兼容特性正在吸引内部越来越多的开发者以及业务用户。
在线教育业务也在积极的拥抱这套框架，逐步将各业务牵引到tRPC框架。在解决历史技术架构痛点的过程中，通过微服务构筑，形成微服务群，构筑稳定的支付,音视频等小中台以及面向C、B 端用户的互联网业务系统。
04
中台
中台，是最近几年最火热的技术名词之一，关于中台的讨论，甚至是争论，一直都没有停止过。最近，随着阿里不搞中台了的声音，很多人开始有个疑问：搞中台错了吗？借这个机会，我们尝试结合腾讯在线教育部在中台方向的实践经验，谈谈中台对我们的意义和建设情况。
腾讯在线教育部从2018年开始规划部门内的中台建设，2019年基本完成组织架构和技术架构的中台转型。我们和大多数公司一样，并不是从0开始构建中台，而是在保证现有业务快速迭代的前提下，同时完成架构的转型，大家形象的称这个过程是“开着飞机换引擎”。对于一个风险看起来这么高的事情，在决定做之前，我们要回答好几个问题：
1. 我们为什么要做中台，部门需要什么样的中台？
我们部门主要有三款产品：腾讯课堂——职业在线教育学习平台，具有2B和2C的双重属性。支持教育机构的入驻、直播上课、售卖、结算 等功能。腾讯企鹅辅导——腾讯自营的，主打K12名师教学的学习应用，为老师和学生提供了丰富的在线教学的功能。腾讯开心鼠英语——主打3-8岁的少儿英语学习，通过生动有趣的交互式学习设计，实现了边玩边学的有趣的学习体验。可以看到，这三个产品有不少类似的功能，例如直播、回放、支付、退款 等，因为这些共性，决定了他们会有很多相同的产品和技术需求。这些形成我们做中台的业务基础。
在产品发展的初期，由于时间窗口非常紧，需求变化也很频繁。为了快速并行迭代，我们拉起了三个独立的团队进行研发，除了基础设施外，业务逻辑部分完全是独立的。这种组织架构，在当时确实为我们达成了上线时间的目标，帮助产品实现了从0到1的突破。但是，随着产品形态的成熟，3个问题越来越突出：第一个问题，功能无法在不同的产品间快速复用。因为独立的代码和架构，复用变得非常的困难，很多开发同学反馈复用代码还不如重写一遍更快。第二个问题，同类的Bug的解决和技术优化在不同的产品之间重复进行，非常的浪费人力。第三个问题，不同的时期，我们需要发力的产品方向不一样。当一个产品面临发展窗口期的时候，对研发人力的需求就会成倍的增长。而独立的研发模式，让人力调配非常的困难。基于业务的模型，和团队碰到的痛点，我们提出了中台化的解决方案。
我们需要的中台应该长什么样子？经过前期的思考，我们总结出在线教育的中台应该包含4个部分。首先 是业务支持部分，这个很好理解，包含了各类共性的产品功能，例如前面提到的 直播、回放、支付 等等。其次 是技术支持部分，服务开发过程中 必然会涉及到例如 技术栈怎么选择，高可用怎么做 的共性技术问题，我们希望这部分有一个统一的技术实现。 接下来 是数据支持部分，数据上报、计算、汇总、分析 已经是现在互联网产品必不可少的能力，也具备很强的通用性。因此这部分也应该有一个中台来承载。最后，是研发效能部分，我们需要有一整套好用的工具来提高研发效率和保障研发质量。到这里，我们对于中台的模样，应该是比较清晰了。
根据这个规划，我们画出了我们中台的组成图。
2. 怎么保证中台能做成功，最大的风险是什么？
很多人说，中台是“一把手工程”，意思是一定是自上而下推动的，需要老板的鼎力支持，是因为做中台确实是非常的需要人力，并且很大程度上改变了团队的资源投入模式，在多个业务需求压力都很大的情况下，做这么大的转变，团队短期内一定会碰到各种不适应的问题。虽然我们的中台方案也得到了老板的支持，但是绝不是中台优先，毕竟保障业务的高速发展才是团队追求的结果。一开始我们就意识到了困难的存在，为了不让中台死在半路，我们定了几个原则：
- 控制人力占比：在人力有限的情况下，为了保障业务需求不受太大的进度影响，中台的人力投入原则上不超过总人力的30%。
- 不做过度设计：中台的设计目标只控制在部门内的需求（腾讯课堂、企鹅辅导、开心鼠英语），不面向行业做完全通用化的设计，根据实际需求做决策。
- 完整规划，逐步实施：在做好完整的技术方案设计之后，我们不追求一次性完成中台的建设，而是结合业务产品需求的情况逐步实施，每半年也会review一次方案是否需要调整。
以上的规则，可以说很好的帮助我们保障了中台平滑转型的过程。另外，我们也在一个合适的时间点进行了团队人员组织结构的中台化匹配升级，保证了技术架构和组织架构的一致。
3. 中台建设的指导原则是什么，目标是什么？
我们中台服务设计的原则是什么，应该做哪些，什么时候做，做到什么程度。这个在业务部门里面其实是一个非常棘手的问题。很多时候我们需要在“时效性” 和 “扩展性”方面做选择。
最后我们总结出来的一套方法是这样：对于一个新的需求，如果看到了可复用性，优先让业务团队自己做，一般这种需求时间紧、不明确，如果这时候讨论宏大的中台设计，往往效率低，耽误上线时间，但是，我会在过方案的时时候问大家“通用性是怎么考虑的”，最终在方案设计上做好通用型的前期准备即可。后面如果再次收到另外一个产品的类似需求，这时候我们就认真考虑要把这个服务交接到中台组来维护了，由中台组安排人力来进行中台化。最后再有新的业务接入，就直接由中台组来承接了，就会非常的简单，我们很多中台服务都是这么跑出来的。
还有一个需要思考的问题是，中台服务的建设目标是什么。提出这个问题的背景是，我们希望给中台团队一个统一的、清晰的阶段性目标，当然也可以用来做团队考核。我们总结出来三个点：
- 功能的复用：这个是最基本的，也是提出中台的初衷。具体到落地上，必须是一套代码。
- 统一运营：要求中台服务能分产品输出标准化的实时监控看板和报表邮件，让业务一目了然。
- 容灾调度的能力：不同业务的多套部署之间，在紧急情况下可以互备。需要进行实际的线上演习。
我们认为，达成这三个目标之后，才真正的发挥了中台的威力，可以实现 1+1大于2 的效果。
近期热文推荐
你“在看”我吗？