前言
我们知道，在一个技术领域里，随着技术的发展，最优解永远在变化。同样，一个业务系统也一样，从初期创建到承接的业务量和业务场景的不断变化，在不同阶段时，面临的问题和系统的设计思路也是不断变化的。
之所以想分享一下系统演进过程，是因为每个系统的业务场景和发展阶段虽然不同，但在技术实现上，回归到系统本身的设计和优化思想是万变不离其宗的，不同发展阶段的技术变化也基本是遵循一定规律。所以，本篇文章通过结合培优呼叫平台随着业务发展阶段的变化而采用的技术手段和架构优化，去看一下系统架构设计一般会经历的阶段，以及每个阶段都解决了哪些问题，同时会引出哪些问题。
系统发展
总的来说，培优呼叫平台起步较晚，目前所处的阶段也是比较初级的（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 微服务-呼叫自身业务更细粒度的模块化
微服务是目前正要进行的一个阶段，随着业务的发展、场景和能力的不断拓展，呼叫平台本身也将要步入自己的微服务化建设，这本身与初期呼叫业务服务拆分，提供独立的服务平台并不冲突，是分布式服务架构的进化版，因为每个服务本身就是随着业务一步步生长、不断积累的。在当时，相对于原有业务系统，呼叫本身就是一个客服模块、就是一个最小业务单元，但随着客服体系的发展，现阶段呼叫已经成为与原业务系统同级别的系统了，已经有了自己的工单、任务、流程等业务单元/模块，各模块之间的可伸缩性、可扩展性及高性能需要更精细化的管理。
【关键演进：系统架构演进之微服务】
微服务虽然也是一种业务服务拆分，都是进行「拆」的操作，但也不完全等同，相对于业务拆分粒度更细，有一定的区别：
拆分方式不同：
业务服务拆分是将系统按照业务划分进行拆分，让拆分之后的服务区分担原单体服务的业务。
微服务则是在业务拆分基础上进行更细粒度的拆分，通过将服务拆成更小的模块，让一个方向下业务的每个小模块都可以独立运行，又能高效协同、管理。
部署方式不同：
业务服务拆分后，与常规服务部署一样，一般也是独立的服务器集群进行部署。 微服务不一定部署在多个服务器上，可以同时部署在统一服务器上。
目的/作用不同：
业务服务拆分：分散压力，是为了解决单体应用资源有限且耦合的问题，在一个服务器上无法支撑不同业务维度的用户更稳定更高的访问，然后通过服务拆分的方式部署到不同的服务集群，从而分担业务、分别处理业务。
微服务架构：分散能力，是需要对服务组件进行精细化设计，更好的进行服务解耦，让服务之间通过组合的方式完成高性能、高可用、可伸缩、可扩展的建设。
其次，分布式服务架构强调的是服务化以及服务的分散化，微服务架构通常是一种分布式服务架构，但微服务则更强调服务的专业化和精细分工，需要一定的专业知识和技术积累。所以，选择微服务通常意味着需要解决分布式架构的各种难题，在业务没有规模有没有太多变化的情况下，贸然采用/为了用而用微服务架构，会引入各种复杂性（如：部署工作、链路监控、服务治理等问题），得不偿失。
总结
系统的演进应该是一个循序渐进的过程，要以解决系统中存在的问题为目的和驱动力。需要根据实际业务所处的阶段进行选择，不能盲目的追从，要能压住技术伙伴的追求技术的躁动的心，脚踏实地一步一步的随需而变的进行。适合的才是最好的！
在系统演进过程中，可以根据实际情况遵循一定的思路进行：选择最熟悉的技术体系，通过最简单的系统设计满足业务需求和流量现状。
优先通过团队熟悉的技术组件和系统架构优化，去解决随着业务量的增加、业务场景的不断演进而出现的问题（如：单点问题、扩展平台、性能问题、存储问题等）。
然后才是通过系统重构去重新整体业务和架构调整解决问题。
本文是根据实际系统经历进行一些总结，路径和方案并不是标准和最佳实践，欢迎交流学习！
