云计算典型架构十讲之高并发互联网业务架构

上四节他们讲了在云环境里，适用于于任何应用领域的高可用构架，这四节他们选取了较为有代表性的网络销售业务，因为适用于面也相较很广。

他们在工作中接触的最多的也是网络销售业务，尤其以电子商务、小流程居多，网络销售业务的特点是规模大、使用者多、增长快、波动大，同时也属于来钱较为快的行业，网络公司能雇佣的起低薪流程员，反馈到销售业务上是能塑造出各种各样的机能，吸引使用者留下来，这意味著模块多、模块多是必然的，相同的机能背后需要相同的控制技术栈去实现，这也造成网络构架会相较繁杂一些。

对于网络构架而言，他们要从关键点看需求，把关键点一两列出来，匹配相同的化解方案，再组织起来，就成了两个完整的构架方案。

那具体来说他们要面临的是架构是不是具有充足的灵活性，因为网络销售业务的波动性相比其他销售业务而言是更大的，比如说送餐APP，每天中午和下午使用率非常高，其他时段就很低，又比如说淘宝应用领域，一到做活动的这时候使用者会多出十倍十倍，还有很多财经新闻类应用领域，一有热点事件，服务项目器的压力就很大。

所以，构架的灵活性是具体来说要化解的问题，也应该在整座构架设计中充分考虑到每个模块的灵活性。从前端销售业务逻辑服务项目器而言，他们前面已经说到了，使用代销的阻抗平衡能防止单点故障，能让服务项目器横向扩展，那时两台明天三十台，后天又变两台，这是没问题的，代销的阻抗平衡本身也能纵向扩容，提升QPS和频宽峰值，还是一样的，防止服务项目器间展开繁杂的统计数据同步。

在这一步，使用者能借助灵活性伸缩来化解，也能手动往阻抗平衡集群添加服务项目器，来达到灵活性的目的。

那从具体的资源安排上，阻抗平衡作为流量的总入口，有些使用者会在后端再做一层交换机，可能是应用领域身份验证、帐号体系，这通常适用于于特大型的应用领域，更多的使用者会直接装载真正运行销售业务的服务项目器，也是图中的APP ABCD这些机器。

那么网络销售业务的第二个关键点，是销售业务繁杂，淘宝网的控制技术负责人曾经在公开论坛上说过，那时他们在淘宝网APP上做两个付款动作，淘宝网后台销售业务会初始化330个服务项目，这是2019年的统计数据， 那那时肯定会沙埃，他们能想到的，仓储的库存服务项目、电子信箱服务项目，对吧，付款时的支付、科季夫、提成、买赠、淘金币、淘宝网客、佣金，对吧，Bokaro，不止是淘宝网，那时几乎所有的应用领域流程单厢收集使用者统计数据，分析使用者行为，给使用者打条码呀、画像呀、精确发送呀，这另一面都是相同的控制技术来合力完成的，那在控制系统构架里，就意味著N多个模块间的互通和相互初始化。

当服务项目多了起来，相同服务项目间的可信通信就成了两个大问题，比如说订单控制系统初始化提成服务项目，如果在大促秒杀期间，某两个服务项目这么一来崩盘可能会导致整座信道展开不下去，这个这时候一般会引入最新消息堆栈来展开可信最新输入输出，作用有两个，两个是解耦，把相同服务项目间的初始化解耦，两个服务项目崩盘不至于击垮整座流程，另两个是削峰Viluppuram，主要是削峰，在销售业务规模大的这时候，生产出的最新消息被临时存在最新消息堆栈中，让下游服务项目根据自己的性能慢慢消化。

业界实现最新消息堆栈的形式也有很多，比如说阿里巴巴的rocketMQ，开源的rabbitMQ等，都是实践中应用领域的较为多的堆栈服务项目，那在云上的环境中，使用代销的最新消息服务项目能免去自建的运维麻烦，因为最新消息服务项目本身也涉及两个高可用问题，如果在mammalian高的这时候堆栈本身这么一来了，那还是白忙活，所以代销的堆栈服务项目一般是以服务项目的形式交付，使用者只需要创建最新消息通道，至于最新消息通道的吞吐量、自身的环境这些都是云平台处理的，使用者也基本不用担心队列服务项目本身出问题，云平台一般是以最新消息API初始化次数计费，性能、吞吐量是灵活性自动扩展的，使用者不需要做什么额外的升降级动作。

在文件控制系统方面，使用者能选用代销的NFS文件控制系统，按照实际存储量计费，也是自动弹性扩容的，使用者不需要提前买一堆磁盘，还要关心什么这时候满了，什么这时候需要扩容了。

在统计数据存储上，网络销售业务一般单厢涉及登录、支付、投票之类的动作，关系型统计数据库是少不了的，oracle、mysql、SqlServer是最热门的三种关系型统计数据库，用云平台的PAAS服务项目也能省去很多麻烦。

那网络销售业务的第三个关键点是高mammalian，这些年不管什么平台都喜欢造节，从最早的黑色星期五，天猫双十一，到这两年的618、女王节等等，单厢引导所有使用者在集中的某一两天去付款，打着便宜的旗号做营收，当然好坏他们不论，不是他们讨论的重点，重点是造节会人为的加大mammalian量，本来大家都是平稳的每天几十万单，为了笼络消费者，在双11那天用红包、折扣促销，会产生几千万上亿比订单，这对IT控制系统的考验是非常巨大的，前期营销费用都砸了下去，如果到了办活动这天，控制系统这么一来，就前功尽弃了。

那，从实践上来看，IT控制系统出问题，往往都是有状态的部分出问题，统计数据库更是重灾区，前端的销售业务逻辑机器很简单，一股脑加机器就能提高运算量，但是统计数据库这里单机容量是有限的，性能也是有限的，在mammalian量突然爆发性增长的这时候，可能瞬间会打死统计数据库服务项目，尤其是关系型统计数据库是经不起这样的折腾的，所以这里一般会引入缓存统计数据库redis做一层拦截，把实时的热点统计数据放进redis里，因为redis是基于内存的，速度很快，mammalian量很高，但是这也决定了它的容量不会很大，当高mammalian来的这时候，销售业务服务项目器会先去redis里取统计数据，如果redis里有，就直接返回给使用者，如果没有，再去关系型统计数据库里取，这也能很好的分担关系统计数据库的压力。

业界为了化解这个问题，还会引入其他统计数据库，比如说电子商务网站上会有大量的商品详情页，会涉及很多文字介绍，每种商品都有自己的说明、规格，都不一样，那mongoDB是存储这类文档统计数据的好手。

这里要着重提一下，如果屏幕前的你是云计算从业者，你不应该生搬硬套这些东西，每个客户采用的控制技术栈相同，有些使用者不用缓存，有些在开发时就设计好了，有些使用者用Hbase存非关系统计数据，有些又用到了ES等等，总的而言一句话，使用者开发时用了什么，就采用什么样的云资源，上面列举的仅仅是热门典型方案，并不等于适用于所有客户。所以作为从业者，关于redis、mongoDB等这些软件还是要有一定的了解，至少要清楚它们的特性分别是什么，适用于于什么样的场景。

网络销售业务的第四个关键点是海量的音视频、图片存储，大家想想看你手上经常打开的APP里，是不是以视频内容呈现的居多，因为视频、图片是有感染力的，文字是略显苍白的，需要动脑，所以能用视频表现的内容，不会用音频，更不会用图片，这就造成像电商、娱乐、咨询这类网络APP的文件存储量非常大，除了存储，还涉及到海量文件的分发，还要高效分发，使用者打开不能卡顿、等待。

这里就会引入对象存储和CDN来搭配使用，对象存储负责存储海量的音视频、图片文件，供销售业务控制系统初始化，CDN负责把这些图片视频通过全国的节点高效分发，还能节省使用者的频宽，降低成本。实际上他们在工作中也会遇到客户不了解CDN，一直是用频宽在抗着图片、视频的流量，用了CDN以后效果就好多了，成本也会低很多。

第五个关键点，也是经常被忽略的一点，是网络销售业务的网络安全问题，因为网络销售业务来钱快，增长快，也就很容易被黑客盯上，黑了控制系统、删了统计数据、锁了文件然后敲诈，这是一种常见的动机，是图财的，另一种是被竞争对手恶意黑掉，比如说在线棋牌游戏这种，举个例子，陕西麻将的玩家全国就那么多，总量基本是恒定的，那在线陕西麻将这个细分领域里，每多两个公司，那每个公司的收入单厢下滑，因为蛋糕就那么大，所以棋牌游戏公司间的恶性黑客攻击是非常常见的，这种属于是要搞死你，也不问你要钱也不敲诈，打的你的游戏天天掉线，玩家玩不了，使用者就会来我这边。还有是各种漏洞、病毒、竞争对手爬取统计数据这些，都是必须要防范的。

所以在销售业务安全上，适用于于几乎所有使用者的有WEB应用领域防火墙和云主机安全这两个，第两个也叫WAF，业界有开源的WAF，也有云平台提供商业WAF，它是作用是防止CC攻击、跨站攻击、SQL注入和常见的7层攻击，选用商业WAF有个好处，这些产品通常都是云厂商安全团队经验的结晶，他们大平台受到的攻击不管是体量还是花样都远远多于小公司，所以经验也最多，防护也是最有效的。

他们在工作中也见了不少，属于客户被攻击了，但是他自己不知道，等黑客拿着统计数据来要挟要卖的这时候才知道已经被攻击了。

WAF的原理，是通过域名解析的形式，把APP、网站的流量接管，任何访问请求进来，不管是恶意的还是正常的，单厢进入WAF清洗池，根据安全规则，把正常使用者的请求放行给后面的阻抗平衡销售业务集群，把黑客发起的恶意请求拦截掉。

另两个是服务项目器安全，主要是防病毒、杀木马，属于操作控制系统层面的防护。

中小企业一般这两个就够了，也是应用领域的最多的，最有效的。

最后，图中他们还看到了NAT交换机，前面学了网络章节的同学应该都能想到它是干嘛的了，现在网络应用领域单厢涉及支付，但是持有支付牌照的公司是没几家的，大家无非都是初始化微信支付、支付宝支付，所以销售业务构架本身肯定会涉及外部API初始化，也是集群内机器向网络上的其他机器发起请求，那用NAT交换机能集中管理，也更安全。

好，那构架解析就不再赘述了，他们直接看构架要点。

具体来说，每两个模块的引入，都是为了化解业务发展中特定的问题，遵循奥卡姆剃刀原则，如非必要，勿增实体。

对于云原生的产品，尤其是像对象存储、最新消息堆栈等，一定要提前了解特性，贸然接入反而可能会适得其反，徒增工作量。

第三个是网络销售业务增长快、波动大，这对运维人员提出了更高的要求，在团队熟悉的控制技术栈范围内，合理使用代销服务项目能大大减轻运维压力，也能使IT团队专注于销售业务开发和迭代。

第四个是在设计网络销售业务构架时，要充分考虑到未来的灵活性，而且要和成本相结合，在当下的构架能够满足销售业务运行的同时，确保应用领域流程能应对潜在的爆发性增长。

第五个，即使是最有经验的构架师也没法精确预估销售业务规模的变化给控制系统构架带来的挑战，设计完善的压力测试、场景演练是很有必要的。