架构训练营 0 期总结 -- 第四周

传统的系统比较大型的就是银行系统，银行有钱动辄就是几亿美金的预算，阿里云上一个2C4G的服务器一个月300RMB左右，一个省级的银行中心系统也许是一个中型机，如果中型机不行那就继续买大型机。当然大型机和一个普通的阿里云服务器的性能一个天上一个地下，拿出来做比较的原因是：银行因为都是基于网点来做交易的，流量入口就有限制而且相对较低(相对淘宝)，所以高性能服务器就能抗住所有的业务。我们一个网点一天办理1000次业务，全国我们算2万个网点，也就2000万服务总次数，而且这个还是一天的(银行5点就下班)。大型机就能抗住的情况下，就不需要类似互联网复杂的架构设计。



那么互联网架构主要复杂在哪些地方呢？



一、高并发、大流量

1. 谷歌日均PV 35亿 独立IP大概3亿

2. 微信的在线用户数10亿

3. 双十一一天的交易额破3000亿



二、高可用，互联网系统7*24小时提供服务



三、海量数据

1. facebook每周上传的照片数量10亿量级

2. 百度收录的网页数量破100亿

3. 谷歌有近100万台服务器提供服务



四、网络环境复杂

互联网是面向全球用户服务的。为了让国外的用户能体验国内的一些app，国外也会建一套服务。美团在国内还分了南北服务中心，为的就是减少因为地理原因造成的数据延迟。我最近在做一个出海的项目，粗略的通过物理距离和光缆传输数据就能知道物理的延迟是多少，而且中美光缆经常出现问题，之前支付宝的xxx机房光缆也被挖断了。



五、安全环境复杂

银行通过内网进行系统同行，专线！淘宝却是全球所有人都能访问的，我最开始也想过我要是能黑进支付宝神不知鬼不觉的余额增加7位数，奈何我没这个能力，但是有这个想法的人不少，有一百万人有这个想法，每天有事没事发动一点攻击，怎么看都是个非常麻烦的事情。



六、互联网时刻都在变

一直都在讨论敏捷编程，敏捷两个字估计在互联网更明显不过了。需求快速的变更，应用频繁的发布，这些都是对架构的严格要求。传统的软件，在着手开发之前，复杂的软件估计都得设计个半年。FB是在寝室写出来的，Google的第一台服务器在学校的实验室，阿里巴巴诞生在马总的客厅。



面对这些挑战我们的架构的演进方向是什么？

简单的说来：垂直伸缩和水平伸缩。垂直伸缩用简单的话来说就是用更好的机器，好处是不用做其他的额外事情，缺点是机器很贵，而且有极限。水平伸缩就是加更多的(廉价)机器，在对外服务上能切分的比较细，在性能可被接受的情况下，通过一些分布式的负载手段让每一台机器都能达到最大吞吐量，而且理论上机器越多吞吐量也就越大，没有极限。



水平伸缩的先后顺序大概是什么样子的？

以一个创业公司来举例，最开始一台负载均衡服务器，应用服务器，一个数据库，一个文件服务器。



第一步：引入缓存。分布式缓存和多用应用的本地缓存，可以极大程度的改善单台应用服务器的吞吐量。

第二步：应用服务器集群部署，简单来说，业务撑不住的情况下要首先扩容应用服务器，数据库这个时候是撑得住的。

第三步：数据库读写分离。应用服务器集群化之后，业务处理逻辑撑住了，如果业务持续增长那么增加应用服务器数量就行了。加到一定程度，数据库就扛不住了，这个时候先主从，读写分离，足够撑着业务一段时间了。

第四步：应用服务器足够了，数据库也能撑住了，缓存也让单机的吞吐到最高了。接下来我们就需要让我们的前端应用变得更快。静态资源引入CDN，同时引入nginx反向代理加速访问的时候同事处理一些不需要应用服务器参与的业务。

第五步：如果业务继续前进一大步。瓶颈在哪里？一般来说简单的主从已经撑不住了，主从只是分离了读写，数据量还是一样大。所以要切数据库，分布式数据库就在这个时候引入了。分布式数据库就是把数据切分了，比如用户id为基数的在一个库，偶数的在另外一个库，或者1-1000000在一个库 1000001-2000001在另外一个库，又或者用户的数据在一个库，订单的数据在另外一个库。如果业务里面还有一些类似的系统比如文件系统，那么这个时候也应当一并分布式掉，原因也是一样的。

第六步：拆了数据库会带来一些问题。以前一个数据库就能解决的问题，现在办不到了。核心的功能就是搜索和数据统计。所以我们得映入其他的一些改变：搜索引擎和nosql数据库。搜索引擎用于解决搜索问题，常用的是ES，nosql常用的mogondb，Hbase。

第七步：其实现在整个从前到后已经不错了。但是要到这个阶段业务应该达到了一个不错的量级，技术应该也有好几十人。如果不做任何改变那么这个团队在日常的开发中会一般来说都是乱糟糟的，重复的劳动也会非常多，氛围也会比较差，产品经理难受（需求给出的排期总是不准），开发难受（各种协作，代码合并问题），测试难受（刚测试完，另外一个人合并了代码进来，又得回归）。所以这个阶段要对人员做盘点，同时也是对系统的进一步审视（隐藏着对团队成员的架构梳理）。对老板说，要想技术支撑10倍业务，我们需要把系统微服务话，摊出人员架构，让每个人能更专注的在单个领域、有成长。这也是技术总台的基础。拿一个电商业务来说至少会有会员、交易、优惠、支付、商品、库存等微服务。中台的建设过程是把事情做细、做可靠的一个过程，业务培养领域专家的一个过程！

t第八步：其实上面说的每个步骤，都只能算是那个步骤的LV0。每个步骤接来下会有他们自己的LV1、Lv2等等。不过当我们完成第七部之后我们还有一件重要的事情要做：数据中心。数据中心最好就是在中台做好之后做，因为中台完成之后整个系统就会很清晰干净，同事整个过程的数据相对来说结构化程度高，会大大的减轻数据中台数据分析的难度。我们总不希望数据中心80%的时间在洗数据，20%的时间在分析数据，产出可指导运营的支撑数据吧？如果是这样这个支撑数据估计会让市场和运营拿着刀子追着你砍。



到这里，lv0应该就差不多结束了。剩下的就是各个模块内部的集群化，架构升级、性能提升、业务模型的迭代升级等。