新东方APP技术架构演进， C端技术经验分享

古代东西方的思想家都产生过一个终极的追问，世界的本元到底是什么？ 老子说，道生一，一生二，二生三，三生万物，天道有常不以尧存不为桀亡。孔子说朝闻道，夕死可矣，孔子把对道的研究从，对人与自然关系的天道，转移到了研究君君臣臣父父子子的人道方向上。古希腊第一个哲学家泰勒斯说世界的本元是水，后来毕达哥拉斯回答说世界的本元是数字，古希腊哲人对道的研究始终聚焦在人与自然关系的天道方向上。对终极追问的不同思考和回答，衍生出了，东西方在文化价值观，思考逻辑和做事方法等方面的巨大差异。

我们在企业里工作，实际上也存在一个终极追问，就是你的终极用户是谁？怎么服务好终极用户。我曾经在2B技术公司IBM工作过12年， 在2C技术公司滴滴工作过三年。 我深切感受到，在这个问题上的不同回答，导致了传统的IT技术公司和互联网技术公司， 在工作价值观，和工作方法等方面的不同。

通常，B端技术重功能不重体验，软件客户每年续签一次合同，软件开发商可以通过各种手段增加用户迁移到其他竞争对手的成本，深度绑架用户，即使客户对软件有一些不满意也会续签合同。 而互联网的C端个人用户是典型的用脚投票，抛弃一个产品的时候，一声再见都不会说。 因此互联网产品技术的竞争是典型的赢者通吃，产品体验稍有不同，短时间内用户就会流失到竞争对手那里。所以互联网产品技术极度关注用户体验，和用户客诉。 IBM解决客户的客诉流程冗长，有所谓的一线二线三线技术支持，解决一个客诉动辄数月之久。 但是互联网C端技术需要时刻关注用户客诉和线上事故，争分夺秒的解决问题，甚至要求几分钟内就把问题解决掉。 所以如何避免和减少客诉， 如何快速处理线上故障，就成为区别2B，2C技术公司不同点之一，对价值导向问题的不同回答，也产生了完全不同的价值评估系，最简单的就是如何去判断一项具体工作的轻重缓急和重要程度。

我刚来新东方的时候， 我的团队里没人关心客诉问题，没有技术值班，上线流程很草率。 互联网公司里重要的技术方法到了IBM那里，就可能变成过度设计，变成不重要的工作，但其实没有毛病， 因为俩者的业务场景和最终用户是完全不同的。所以一定要认识清楚，我们工作的end user是哪些人， 以及如何服务好最终用户。 当最终用户满意时，我们的工作自然就会被公司认可。所以我认为很多事情不是技术问题，而是价值导向问题，价值导向对了，我们的技术规划，架构选型就自然做对了。我是被IBM培养出来的，但到了滴滴后，只要愿意改变，一样也能做好互联网的技术工作。

在互联网产生之前，最大的计算机系统就是银行柜员系统，用户必须去银行网点排队办业务，银行网点人满为患，所有的交易都通过柜员处理， 大家想想看，这实际上就是通过人工排队的消息队列进行了削峰限流，最后所有交易都集中在一台价值几亿人民币的 IBM大型计算机里， 在集中式的DB2或者Oracle数据库里完成交易。 今天互联网电商的交易量要比银行大的多，所有的系统都是分布式系统了，与以前的集中式系统相比，分布式系统最显著的特点就是容易扩容，今天银行的IT系统也都互联网化了，大多数的银行业务都可以足不出户在家自助办理了，所以我们必须看一下什么是分布式系统

分布式系统是由许多计算机集群组成的，但对用户而言，就像一台计算机一样，用户感知不到背后的逻辑。分布式系统最重要的理论是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理论是对CAP理论的延伸，是指基本可用、软状态、和最终一致性。基本可用， 比如在规定的1秒内熔断了，没有返回结果， 那我们又重试了两次，结果返回了结果，这个就是基本可用。 假如我重试了两次后，还是失败了， 我们做了一个降级处理，让用户仍然可以继续使用服务，这个也叫做基本可用。