新西方APP技术架构演进

kk_kiki

前言
现代货色方的思想家都发生过一个终极的诘问，世界的根源究竟是甚么？老子说，道生一，终身二，二生三，三生万物，天道有常不以尧存不为桀亡。孔子说朝闻道，夕死可矣，孔子把对道的钻研从，对人与天然瓜葛的天道，转移到了钻研君君臣臣父父子子的人道标的目的上。古希腊第一个哲学家泰勒斯说世界的本元是水，起初毕达哥拉斯回答说世界的本元是数字，古希腊愚人对道的钻研一直聚焦在人与天然瓜葛的天道标的目的上。对终极诘问的不同思考和回答，衍生出了，货色方在文明价值观，思考逻辑和做事办法等方面的微小差别。
咱们在企业里任务，实际上也存在一个终极诘问，就是你的终极用户是谁？怎么办事好终极用户。我已经在2B技术公司IBM任务过十二年，在2C技术公司滴滴任务过三年。我深切感触到，在这个问题上的不同回答，致使了传统的IT技术公司和互联网技术公司，在任务价值观，和任务办法等方面的不同。
通常，B端技术重功用不重体验，软件客户每一年续签一次合同，软件开发商能够经过各种伎俩减少用户迁徙到其余竞争对手的本钱，深度绑架用户，即便客户对软件有一些不满意也会续签合同。而互联网的C端集体用户是典型的用脚投票，丢弃一个产品的时分，一声再见都不会说。因此互联网产品技术的竞争是典型的赢者通吃，产品体验稍有不同，短期内用户就会流失到竞争对手那里。
所以互联网产品技术极度关注用户体验，和用户客诉。IBM解决客户的客诉流程简短，有所谓的一线二线三线技术反对，解决一个客诉动辄数月之久。然而互联网C端技术需求时辰关注用户客诉和线上变乱，分秒必争的解决问题，乃至要求几分钟内就把问题解决掉。所以如何防止和增加客诉，如何疾速处置线上毛病，就成为区分2B，2C技术公司不同点之一，对价值导向问题的不同回答，也发生了彻底不同的价值评价系，最简略的就是如何去判别一项详细任务的轻重缓急和首要水平。
我刚来新西方的时分，我的团队里没人关怀客诉问题，没有技术值班，上线流程很粗率。互联网公司里首要的技术办法到了IBM那里，就可能变为适度设计，变为不首要的任务，但其实没有故障，由于俩者的业务场景和终究用户是彻底不同的。所以一定要意识分明，咱们任务的end user是哪些人，以及如何办事好终究用户。当终究用户满意时，咱们的任务天然就会被公司认可。所以我以为得多事件不是技术问题，而是价值导向问题，价值导向对了，咱们的技术布局，架构选型就天然做对了。我是被IBM造就出来的，但到了滴滴后，只有违心改动，同样也能做好互联网的技术任务。
在互联网发生以前，最大的计算机零碎就是银行柜员零碎，用户必需去银行网点排队办业务，银行网点人满为患，一切的买卖都经过柜员处置，大家想一想看，这实际上就是经过人工排队的动静队列进行了削峰限流，最初一切买卖都集中在一台价值几亿人民币的 IBM大型计算机里，在集中式的DB2或者Oracle数据库里实现买卖。明天互联网电商的买卖量要比银行大的多，一切的零碎都是散布式零碎了，与之前的集中式零碎比拟，散布式零碎最明显的特征就是容易扩容，明天银行的IT零碎也都互联网化了，大少数的银行业务均可以足不出户在家自助管理了，所以咱们必需看一下甚么是散布式零碎。


散布式零碎
CAP准则
散布式零碎是由许多计算机集群组成的，但对用户而言，就像一台计算机同样，用户感知不到面前的逻辑。散布式零碎最首要的实践是2002年被迷信家证实的CAP实践。C是数据统一性，A是可用性，P是分区容错性。CAP三者之间是相互矛盾，相互影响的瓜葛。
其中，最佳了解的是A，A是可用性。可用性存在两个症结目标。首先是“无限的时间内”，其次是“前往正常的后果”，假如用户的操作申请前往的是400或者500过错，或者规则时间内没有前往后果产生了超时，那就算是产生了一次不成用。所以并非说，只要产生了线上大范围变乱，整个办事不成用才是不成用，产生400，500过错或者申请超时都属于不成用。
P是分区容错性：当零碎产生动静丧失或局部毛病时，依然能够运转。在散布式零碎中，当一项数据只在一个节点中保留时，万一产生毛病，拜候不到该节点的数据，全部零碎就是无奈容忍的。假如这项数据复制到多个节点上，某个节点数据拜候不了时，零碎依然能够从其余节点上读到数据，零碎的容忍性就进步了。然而多个数据正本又会带来统一性问题。要包管统一性，每次写操作就都要等候整个数据正本写胜利，而这类等候会侵害零碎的可用性。总的来讲就是，数据正本越多，分区容忍性就越高，但要复制更新的数据就越多，统一性就越差。所以CAP就是一种按下葫芦，就起了瓢的觉得。
C是数据统一性，散布式零碎的数据统一，是指一切办事器节点在同一时间看到的数据是彻底同样的。假如胜利更新一个数据项后，一切的办事器节点都能读取到最新值，那末这样的零碎就被以为是强统一性的。零碎假如不克不及在规则时间内达成数据统一，就必需在C和A之间做出选择。留意规则时间内是很首要的。
当初的零碎都是散布式零碎了，P是不成能保持的，但个别来说，架构设计要尽可能增加依赖，零碎依赖的根底架构组件和第三方零碎越多，假如P太强了，全部零碎的C和A，可能都会遭到侵害。架构取舍更多的是在C和A之间做出选择。而没有散布式的CA零碎就是瓜葛型数据库，就是保持了散布式，保持了散布式的扩容才能。
有些场景要求数据强统一，例如与钱无关的与定单无关的零碎，这类场景下，或者舍弃A，或者舍弃P。瓜葛型数据库是强统一的CA零碎， 但若mysql引入了从库，就会在一定水平上侵害数据统一性，但同时换来了A可用性或者读写机能的晋升。
而TIDB采取raft协定，数据保留在最少三个正本里，同时它要兼容mySQL，完成数据的强统一性，所以既然，TIDB引入了P，就只能在一定水平上要舍弃A，读写机能会相应升高。然而加强了散布式的扩容才能，包罗了存储和算力的扩容。所以CAP实践告知咱们，一切廉价都想占到是不成能的，只能按照实际业务需要和价值判别体系，做出取舍。


BASE实践
BASE实践是对CAP实践的延长，是指根本可用、软形态、和终究统一性。根本可用，好比在规则的1秒内熔断了，没有前往后果，那咱们又重试了两次，后果前往了却果，这个就是根本可用。如果我重试了两次后，仍是失败了，咱们做了一个升级处置，让用户依然能够持续使用办事，这个也叫做根本可用。
终究统一性是指零碎中的一切数据正本通过一按时间后，终究可以达到统一的形态。终究统一性是弱统一性的特殊状况。
新西方不同业务零碎对数据统一性的要求都纷歧样，实质区分就是详细的业务能够容忍在多长的时间限度内，达到终究的统一性。
FLP不成能原理
FLP不成能原理，请自行查找解释，此定理告知咱们，不要试图设计一个可以容忍各种毛病并放弃统一的散布式零碎，这是不成能的. 散布式事务也永久无奈完成单体运用级别的统一性。即便如paxos协定和raft协定也会泛起无奈达成共鸣的状况，只不外泛起的可能性很低。所以说paxos是无效的统一性算法，但也不成能做到白璧无瑕。


假如剥离掉详细的业务指标和产品指标，那咱们就会发现，咱们C端技术任务的指标，其实正好就是分别对应后面讲的CAP。然而同时知足三个要求是十分难的，只能按照详细业务场景进行取舍。Tidb的开发商的名字叫PingCap就是一个颇有雄心壮志的名字，意在有限的同时迫近这三个指标。
当初C端零碎都是散布式的，舍弃P是不成能的，并且业务又会要求咱们必需包管零碎的可用性，因此事实上咱们C端技术能舍弃的也只要规则时间内的数据统一性。
通常只有在数秒钟乃至数分钟，乃至1天后，能够达到终究统一就是能够承受的。咱们就义了统一性，换来的就是A的大幅度晋升，和机能的晋升。
新西方App中的C端技术


接上去咱们，结合APP的任务理论分别讲一下散布式零碎罕用的根底架构组件


缓存
首先讲一下缓存。方才讲过了，数据拷贝越多，数据统一性就越差，引入缓存必定会侵害规则时间内的数据统一性，因此数据缓存时间通常不宜过久，耐久化的缓存数据更是荒唐。redis对外提供集中式的缓存办事，只减少了一份暂时数据正本。但Guava是基于JAVA的当地缓存，每台JAVA办事器在当地保留一份数据正本，会明显侵害全部散布式零碎的数据统一性，而且形成相干客诉。
除了数据统一性，使用redis也会波及到零碎可用性问题。Redis其实是一个CP零碎。关于Redis，value越大，读写拜候的提早就越大。使用缓存时，要防止使用大Value和大Key，不然会升高可用性。大值能够采取序列化后紧缩的办法。与大值相同的另外一个运用极端是，大Key小Value，这类Key能够经过MD5紧缩来防止。通常来说redis的均匀get申请应该是数十微秒级别的，这类高速缓存部署时要和运用办事在一致的IDC，防止跨机房部署，由于跨IDC通常会有毫秒级的提早，从而侵害零碎可用性，使用缓存的意义就不大了。
另外，Redis能够使用pipeline进步批量拜候机能，能够想见网络申请数量会因此大幅度增加。


使用缓存时要思考如何进步缓存命中率，对应的就是如何增加缓存穿透率，增加对第三方零碎或者对数据库的压力。
现实形态下，零碎中的热数据应该都存在缓存里。一个极端是压测，欠好的压测设计是，不断地，频繁地，反复地，申请相反的测试用例，其实第一次就是预取，数据变热后，压测快的飞起，然而一到线上实在环境，可能就不行了，由于线上没有那末多反复申请。但在实在业务场景下，能够按照用户的真正的操作序列，预测出来哪些数据将会很快会被用户拜候到，此时，咱们就能采取事后计算和预取数据的办法，在用户后续操作产生时间接从缓存里读取数据。
另外，刚刚产生读写操作的数据，能够以为都是热数据，均可以斟酌预取到缓存。
上面这张图是在剥离掉详细业务后的，APP使用缓存的架构办法。


首先讲被动更新缓存。
首先第一个操作是需求更新数据的事务操作，能够斟酌被动更新缓存。对统一性要求高的业务，事务被动更新缓存时必需从数据库主库读取数据，不然会由于数据库主从提早致使缓存数据和数据库里的纷歧致。还有一种状况，缓存的值是一个聚拢set，需求一次更新得多数据项，这类操作没有原子性保障，就必需用事务保障，需求加锁。所以被动更新缓存的计划是不敷谨严的，容易致使数据纷歧致。还有就是发数据更新动静，这时候候数据变卦MQ必需把一切信息都带上，典型的如binlog。假如只是通知一个变卦事情，可能就会致使缓存数据和数据库纷歧致。所以binglog多是最不易致使统一性问题的计划。但有时分我就是拿不到binlog怎么办，并且谨严的计划显然在技术上会更繁杂，落地本钱会更高。
我想说，不谨严的形式纷歧定就不克不及用，时辰记住业务场景能够补救技术上的缺乏，架构设计时实用主义比完善主义更合用，更能多快好省地解决业务问题。采取甚么计划，首先是要斟酌业务场景是啥，其次是要斟酌，万一出问题了结果是不是可控，不要寻求完善。特别强调，报名续班优惠的同窗，千万不要这么玩，假如非要这么玩，出问题结果自傲。
第6个操作是被动更新缓存，缓存快过时时，产生读操作，能够斟酌要被动读取源数据，更新缓存，当第三方毛病，致使数据源无奈读取时，能够被动延伸缓存时间。做一个升级处置，进步零碎的可用性。
再讲一下当地缓存Guava。比起集中式的redis缓存，当地缓存的正本更多了，数据统一性也就更差了。假如网关不采取特别的散发战略，当地缓存时间倡议要设置的很短，为的是缩短各节点数据终究统一达成时间。详细怎么取舍，仍是要看业务的实际需要。得多数据库调优的任务，终究变为了玄学。就是由于零碎参数太多了。基于CAP定理，你不成能甚么益处都失掉，顾此必定失彼。


其余使用缓存的小诀窍还有设置缓存时间时加一个随机值，防止缓存集中过时带来的问题。剩下几个后面都波及到了，就再也不讲了。


动静队列
接上去，疾速讲一下动静队列。动静队列能够运用到散布式事务，分段式提交里。也能够帮忙零碎架构解耦。能够用来做削峰限流，既不超过零碎承载才能，同时又不丧失用户动静。动静队列办事的SLA是包管动静不丢，但就义掉了动静不重。会反复发送同一个动静。所以就要求消费者包管操作的幂等性。
消费者的拉动静模型，益处是消费者不会过载，超过最大处置才能。害处是消费者需求专门引入一个独自的办事过程或者线程。
消费者的推模型，消费者构型简略，跟开发一个用户接口同样。害处是可能会过载。
常见动静队列如kafka和rabbitMQ的特征，我就未几讲了。


数据库
上面这张图，我疾速讲一下数据库。


数据库的主库从库读写别离，个别会形成规则时间内的数据纷歧致景象，因此在需求强统一的状况下，能够先读从库，假如读不到，再去读主库，一定水平上能够增加主库的压力。就义了一点儿数据统一性，晋升了零碎的可用性。
分库或者分表能够明显晋升数据库的读写机能。按时归档和分表同样，是增加单表的数据量，晋升读写机能。增加不用要的索引，任何数据库的读写操作，即便没有使用事务，对数据库而言也都是一个事务。为了保障数据库的ACID属性，Insert操作必需在一切索引建设实现后能力前往，因此单表建设过量的索引会拖累数据库的机能。
散布式零碎里，要尽可能防止耗时的数据库操作，好比数据库事务操作，联表查问等操作，由于这些耗时操作，就是让零碎在规则时间内的A达不到了。按照业务特征能够采用终究统一性的概念，结合动静队列，使用分段事务提交的办法，适量延伸达到统一性的时间，来换取零碎可用性的晋升。
在新西方APP的功课零碎里，爆发业就是一个典型的散布式事务。另外，因为先生的报、转、退，和插班举措，发生了得多先生收不到功课，功课紊乱的客诉。因此结合动静队列，分段提交。而且用按时工作扫表，做各种补偿操作，解决了大部份的客诉问题。
结合CAP定理，再说一句，MYSQL是CA零碎，假如mysql减少了从库，也就是引入了CAP里的P，然而mysql主从别离的散布式属性，比起tidb的散布式属性要差一些，由于这样只是扩容了算力，而不是扩容了存储。数据库主从别离，是引入P，就义了C，加强了A，SQL查问变快了。然而关于很短的，规则时间里，要达到数据强统一的业务场景，读写必需都走主库，但还好，这类业务场景是对比少的，新西方的报名续班业务是一个。
结合CAP定理，Tidb是一个典型的CP零碎，最少有三个数据正本，经过raft协定完成三正本数据的强统一。由于引入了P，TIDB的散布式扩展才能比mysql好，无论是存储扩容仍是算力扩容都比mysql好。并且tidb兼容mysql，包管数据的强统一性，所以tidb关于定单买卖业务，是一个很好的选择。这些年银行大大小小的不成用变乱，产生了不下10起，但没据说谁的钱丢了。所以波及到钱和优惠券的场景，宁肯产生办事不成用变乱，也不克不及产生数据统一性变乱，因此CP零碎包管了钱不丢，又包管了散布式扩容才能，是一个互联网时期下的很不错的选择，但规则时间内的可用性就会差一点儿。
熔断升级限流
疾速说一下，熔断升级限流，后面的PPT都提到了。
这里再说一个APP熔断重试的bad case，APP团队之前的零碎里，把Redis配成默许1秒熔断，20次重试。后果有一次，redis产生毛病时，拖累全部APP办事毛病，全都不成用。大家记住redis是CP零碎。
对于限流，有一次，由于内部的爬虫致使APP对教务的拜候减少，流量激增，最初为了零碎不乱，在nginx上减少了限流处置，维护了外部ERP零碎的不乱。


JVM优化
疾速过一下JVM优化。


这一页是APP做JVM优化的实际案例。我笼统总结一下，就是要尽可能防止，一次请求十分大的内存，例如关上一个10几兆的图片，例如，不分页，一次查问10几万条数据库记载。
当年老代内存不敷用的时分，这些内存会间接进入老年代，假如这些操作是对比频繁的，就会致使频繁的Full GC,侵害全部零碎的可用性。优化之后，full GC频率就显著降落了。
新西方App书面语配音功课重构
新西方APP最中心的功用是先生做功课。这张图是之前，新西方APP里趣配音的功课架构，这个架构产生过得多次办事不成用变乱。
大家还记得后面的定理形容，可用性是在规则的时间内要前往正常的应对。而400应对，500应对增多就是零碎办事的可用性升高了。不是非要等全部零碎曾经ping不到才算不成用。
因为功课，无论是上传仍是下载，都占用衔接池的时间太长，所以致使其余办事都遭到了影响，升高了全部零碎的可用性。
用户核心头像办事超时重大，剖析缘故也都是由于NFS存储致使的。所认为了保障功课不乱性，晋升先生做功课的体验，必需撤除掉对NFS存储的重大依赖。


上面这张图是目前新西方APP的趣味配音功课的架构，这个架构对比繁杂，第一次分享，没有润色，略微有点乱。


这个图里的绿色文字步骤都是升级操作。新的架构设计运用了BASE定理，经过根本可用，终究统一等概念，明显晋升了全部功课零碎的可用性。
和旧的架构比拟，新的架构撤除了全部用户交互进程对NFS存储的的依赖，使用腾讯对象存储功课主力存储，NFS升级为备份。这个计划还抵御住了好几回腾讯云的线上变乱。
当腾讯云对象存储产生了毛病时，NFS会被启用，短期内会有一定的数据纷歧致，但因为NFS被设置成对象存储的回源地址，因此两边存储终究仍是会统一的。
腾讯云CDN和对象存储产生过量次毛病，继续时间从数分钟到10分钟摆布不等，咱们的新架构都抗过来了，没有产生任何不乱性问题和客诉，已经有一次，新西方到腾讯云的专线流量激增，就是由于腾讯云的CDN出了问题，无奈拜候，APP端产生大面积升级，带附件上传功课的比例明显减少，查看做业后果视频的升级也同时明显减少。
除了混合云存储，咱们做了自动弹性到腾讯云的混合云计算。当咱们当地的视频分解办事过载时，计算工作会自动弹性到腾讯云的FAAS计算。没有产生弹性时，咱们不需求给腾讯云付钱，产生弹性时，每月100万次下列的计算是收费的。所以能够说，咱们以这类形式，根本没花钱，就增强全部零碎的可用性。
功课是APP最首要的功用，从咱们的价值导向判别，功课不乱性投入再多时间和精神，都是值得的。目前新西方APP的功课零碎曾经被革新成一个打不死的小强。
作者:张建鑫
出处:http://mp.weixin.qq.com/s/xREZmvnMtFI2P0Mx5DeJQQ