关于后端:简述培优呼叫平台系统演进过程

前言

咱们晓得，在一个技术畛域里，随着技术的倒退，最优解永远在变动。同样，一个业务零碎也一样，从初期创立到承接的业务量和业务场景的一直变动，在不同阶段时，面临的问题和零碎的设计思路也是一直变动的。

之所以想分享一下零碎演进过程，是因为每个零碎的业务场景和倒退阶段尽管不同，但在技术实现上，回归到零碎自身的设计和优化思维是万变不离其宗的，不同倒退阶段的技术变动也根本是遵循肯定法则。所以，本篇文章通过联合培优呼叫平台随着业务倒退阶段的变动而采纳的技术手段和架构优化，去看一下零碎架构设计个别会经验的阶段，以及每个阶段都解决了哪些问题，同时会引出哪些问题。

零碎倒退

总的来说，培优呼叫平台起步较晚，目前所处的阶段也是比拟高级的（1.X），尽管系统启动建设时行业中服务化、数据分布式存储、缓存、异步等技术都曾经十分成熟了，但也遵循着零碎设计的法则进行的，是基于本人的零碎建设背景、业务量级的变动，在不同阶段有不同的架构设计侧重点，并不是自觉的在我的项目初期就去为了应用服务化架构技术而间接利用微服务架构、分布式数据存储架构等。（自觉的 / 适度的追从简单的技术架构，会呈现问题难以追究、难以保护等多方面问题）
罗马不是一天建成的，零碎的设计也是如此。
呼叫平台倒退历程

先简略说一下个别的零碎架构的演进的形式：

1. 单体服务器部署的利用与数据一体

  2. 利用与数据拆散
  3. 纵向扩大 / 横向扩大与服务器集群
  4. 减少缓存和异步
  5. 数据库读写拆散
  6. 隔离部署
  7. 分布式数据库和分库分表
  8. 分布式服务架构（业务服务拆分：拆分进去的一个个业务服务随着倒退个别又会反复这个过程）
  9. 微服务
  10. ……
（行业倒退至今，1、2 根本曾经没有零碎零碎会再经验了）

呼叫平台就是老业务零碎（老三代，一个巨型的涵盖培优整个业务性能的，面向各个方向使用者的外围业务零碎）业务拆分后的一个独立业务单元（非服务单元），因而当平台从 0 到 1.X 的建设过程中，也算或多或少经验了这些零碎架构演进的一些环节。

01 业务服务拆分 - 客服专属呼叫平台建设

业务背景：客服人员没有一个对立的工作台，解决一个客户问题通常须要跨多个零碎去查问去操作，还须要联合手工记录等人工形式去解决，业务效率低、客户问题解决率低。

技术背景： 随着业务量的增长，原有的几十人的客服团队也在迅速扩张，客服搭档须要的零碎能力也一直进步，而原有的各零碎除了能力不具备（性能层面暂且不谈），在技术层面，业务顶峰时任意一个零碎或者零碎的某一个性能点呈现瓶颈，都将导致整个零碎的不可用。

例：报名顶峰、上课顶峰系统故障时，最烦躁的是客户，最艰难就是咱们的客服搭档了，因为此时家长的第一个动作往往就是分割客服搭档去解决问题，而客服老师也无奈应用零碎，不仅面临爆线的征询量，还面临无奈解决问题，只能安抚学员的难堪状况。

零碎架构变动（业务服务拆分）：冗余简单的业务零碎 ——> 轻量独立的呼叫零碎

阶段特点和指标： 须要一个独立的、性能聚焦的、用户量和业务量不太高、业务场景简略的专属平台，保障这个平台的服务稳定性和易用性。

能够看到，在这个零碎的承载力、稳定性、扩展性、横向扩大、纵向扩大都曾经成为瓶颈的阶段，须要把一个耦合各业务的零碎拆解成一个个独立的业务服务。其实到这个「拆服务」阶段前，业务零碎自身也曾经通过几个阶段的零碎架构变动，度过并解决了过后阶段的问题，但却曾经无奈解决现阶段的问题了。

原有的业务零碎曾经经验过零碎架构的几个阶段的演进：
数据与利用拆散
服务的纵向扩大 (服务器、数据库、中间件等硬件的一次次增配)
减少缓存和异步
数据库读写拆散

而「业务服务拆分」阶段的架构变动（也能够说是零碎重构），正是一个新零碎的诞生的形式之一。

呼叫平台也就应运而生，从 0 到 1 的建设客服搭档应用的一站式的客服平台，聚焦在高效的、高质量的、高体验的、高扩大的客服专有零碎，除了更精准的反对客服业务，也要可能承接继续增高的并发量、业务量，保证系统的可继续倒退。

从呼叫 1.0 的零碎架构能够看到，并不是从单体利用与数据、数据与利用拆散、繁多 DB 逐渐演进，而在架构初期就曾经建设了集群部署、读写拆散、缓存与异步的根底，跳过了这些阶段。因为互联网技术倒退到此阶段，这些是惯例利用的必备根底了。

【要害演进：零碎架构演进之业务服务拆分】

根本定义：将一个利用拆成多个，部署到不同的服务器中。是当下相当常见的零碎架构演进形式。

解决的问题：代码耦合度高的问题、零碎可维护性低、零碎稳定性问题（鸡蛋不能放在一个篮子）、零碎的承载能力问题，通过业务服务拆分能够更好做到业务模块的高内聚低耦合，每个业务由独立的团队保护，资源更聚焦，技术依赖和服务稳定性更高。

引出的问题：服务间通信、分布式事务、业务数据聚合查问

PS：这里不去深刻赘述业务服务拆分的机会抉择、服务拆分的准则和办法、服务拆分的标准等方法论，这些问题因业务不同，也都有肯定的差别，须要基于规范方法论去 case by case 的参照。

02 服务治理与隔离部署 - 保证系统根本稳定性

矛盾的说，这个阶段很多零碎都不会经验但也存在这样的问题，因为的确算是呼叫平台阶段性的一个架构优化，并稳固撑持零碎到 Step3，所以也出现一下。

为什么说是保证系统的根本稳定性呢？对一个新的零碎就须要服务治理了？又是什么起因就要隔离部署了呢？这就比拟羞愧了，援用一句话来说真的是「技术难度不高，但侮辱性极强」，因为这真不应该是一个技术难题，齐全是零碎架构自身就该具备的根底，但就是应用过程中裸露了零碎设计与产品设计、业务调研的抵触，导致系统能力有所偏离，这也是 Step1 在落地过程中很常见的问题，在零碎架构进行服务拆分阶段时须要留神的问题：

业务类型：呼叫平台不仅仅须要满足惯例的操作类业务，还有一个须要实时高频关注数据报表业务的场景；

零碎须要承载能力：理论零碎应用并发量和业务量远高于预期；

零碎数据量：屡次确认的没有历史数据，到刚应用就必须迁徙大量的历史数据进来，突破承载三年数据量布局的初步设定；

零碎可观测性：当期未设计。

因而，间接导致了呼叫平台疾速进入了新一阶段的架构优化。

业务背景： 并发量和业务量快速增长，高于预期。

技术背景： 外围业务与报表业务部署耦合，且历史迁徙数据量大，零碎稳定性不达标；平台依赖的底层各业务服务较多，呈现问题时短少监测和降级能力。

零碎架构变动： 欠缺服务监测和降级能力，第一是透明化业务问题，进行短期的外围业务服务与报表服务隔离部署。

阶段特点和指标： 稳定性进步，零碎承载能力的瓶颈问题短期失去解决。

基于服务监测和疾速的隔离部署，使得平台过渡到了一个能够撑持业务应用的安稳期，达到零碎诞生的预期。其实这里也是隐含利用的一个零碎演进的场景伎俩「横向扩大」，对老的业务零碎来说，横向扩大尽管曾经无奈解决问题了，然而对呼叫平台来说，就是业务零碎的婴儿版，所以又能够进行新一轮的架构演进，在这一阶段应用「横向扩大」这一策略就比拟适合。

【要害演进：零碎架构演进之横向扩大】

根本定义：减少服务器、数据库等资源节点。是应答突增业务流量的常见伎俩。

解决的问题：通过更多的服务节点去分担负载压力，能够无效的进步性能和可用性。

引出的问题：无状态的利用个别没什么问题，有状态的利用须要思考节点增删带来的业务一致性等问题。

03 分布式数据库 - 保障系统的可继续倒退

这一阶段是很多零碎随着业务的倒退都必然要经验或者设计初期就要思考的，是保证系统有可能应答接下来 3 年、5 年甚至更久业务流量的护身符，也是零碎扩展性的根底，呼叫平台之所以也疾速进入了这个阶段，起因之一除了 Step2 中提到的零碎历史数据量、业务并发量的因素外，更重要的是随着教育行业的疾速倒退，客服团队及客服团队的业务范围也都在飞速增长，是业务重要的抓手之一，通过零碎和数据的观测，到了须要进行「数据库分库分表」的阶段，来奠定零碎继续倒退的根底。

业务背景：业务范围和团队飞速增长。

技术背景：业务数据增长过快，数据量增长较快。

零碎架构变动：数据库分库分表。

阶段特点和指标：数据分布式存储，保障系统可继续的倒退，解决业务量增长过快可能的瓶颈问题。

通过深刻的业务剖析和评估后，基于客服业务的特点，对呼叫平台的几大外围模块进行分表架构革新（程度拆分），这个「分布式数据存储」阶段的演进是原老业务零碎没有经验也不具备可行性的阶段，原业务零碎更重要的问题是业务宏大且耦合重大，不是数据分布式存储能解决的（也不具备施行条件），而拆分后的各个业务服务在应答疾速倒退的行业背景下，刚好非常适合、十分不便的对自有业务数据分布式存储的设计和演进。

【要害演进：零碎架构演进 - 分布式数据库和分库分表】

根本定义：将本来存储在一个库 / 表的数据，分块的存储到多个库 / 表中。

解决的问题：缩小数据库的累赘，保证系统的高稳定性和高性能，反对更多的业务数据存储和利用。

引出的问题：事务一致性问题、跨节点关联 join/ 分页 / 排序 / 函数问题、全局惟一主键问题、数据迁徙 / 扩容问题等。

04 微服务 - 呼叫本身业务更细粒度的模块化

微服务是目前正要进行的一个阶段，随着业务的倒退、场景和能力的一直拓展，呼叫平台自身也将要步入本人的微服务化建设，这自身与初期呼叫业务服务拆分，提供独立的服务平台并不抵触，是分布式服务架构的进化版，因为每个服务自身就是随着业务一步步成长、一直积攒的。在过后，绝对于原有业务零碎，呼叫自身就是一个客服模块、就是一个最小业务单元，但随着客服体系的倒退，现阶段呼叫曾经成为与原业务零碎同级别的零碎了，曾经有了本人的工单、工作、流程等业务单元 / 模块，各模块之间的可伸缩性、可扩展性及高性能须要更精细化的治理。

【要害演进：零碎架构演进之微服务】

微服务尽管也是一种业务服务拆分，都是进行「拆」的操作，但也不齐全等同，绝对于业务拆分粒度更细，有肯定的区别：

拆分形式不同：

业务服务拆分是将零碎依照业务划分进行拆分，让拆分之后的服务区分担原单体服务的业务。

微服务则是在业务拆分根底上进行更细粒度的拆分，通过将服务拆成更小的模块，让一个方向下业务的每个小模块都能够独立运行，又能高效协同、治理。

部署形式不同：

业务服务拆分后，与惯例服务部署一样，个别也是独立的服务器集群进行部署。

微服务不肯定部署在多个服务器上，能够同时部署在对立服务器上。

目标 / 作用不同：

业务服务拆分：扩散压力，是为了解决单体利用资源无限且耦合的问题，在一个服务器上无奈撑持不同业务维度的用户更稳固更高的拜访，而后通过服务拆分的形式部署到不同的服务集群，从而分担业务、别离解决业务。

微服务架构：扩散能力，是须要对服务组件进行精细化设计，更好的进行服务解耦，让服务之间通过组合的形式实现高性能、高可用、可伸缩、可扩大的建设。

其次，分布式服务架构强调的是服务化以及服务的分散化，微服务架构通常是一种分布式服务架构，但微服务则更强调服务的专业化和精密分工，须要肯定的专业知识和技术积攒。所以，抉择微服务通常意味着须要解决分布式架构的各种难题，在业务没有规模有没有太多变动的状况下，贸然采纳 / 为了用而用微服务架构，会引入各种复杂性（如：部署工作、链路监控、服务治理等问题），得失相当。

总结

零碎的演进应该是一个循序渐进的过程，要以解决零碎中存在的问题为目标和驱动力。须要依据理论业务所处的阶段进行抉择，不能自觉的追从，要能压住技术搭档的谋求技术的躁动的心，好高鹜远一步一步的随需而变的进行。适宜的才是最好的！

在零碎演进过程中，能够依据理论状况遵循肯定的思路进行：抉择最相熟的技术体系，通过最简略的零碎设计满足业务需要和流量现状。

优先通过团队相熟的技术组件和零碎架构优化，去解决随着业务量的减少、业务场景的一直演进而呈现的问题（如：单点问题、扩大平台、性能问题、存储问题等）。

而后才是通过零碎重构去从新整体业务和架构调整解决问题。

本文是依据理论零碎经验进行一些总结，门路和计划并不是规范和最佳实际，欢送交流学习！