架构师训练营第 1 期 - 第四周学习总结
本周学习了系统架构方面的一些知识
一、互联网应用的挑战
互联网应用面临的挑战包括以下几个方面:
- 高并发、大流量 
因为很多用户会同时访问应用,所以同一时间点上,会有大量的并发应用,这种并发是传统企业级系统不能比拟的,高并发也意味着大流量,系统会不可避免的受到大流量的冲击。
- 高可用 
基本上互联网应用都是7*24小时可以访问的,如果某个应用说它需要停机1天或者半天,那么它肯定会影响用户的使用,影响用户的体验,用户可能会流失,继而影响企业的发展,所以保证应用的高可用,至关重要。
- 海量数据 
因为每天会有很多用户访问应用,每个用户都会留下数据,比如电商网站,用户浏览商品会产生浏览历史数据,购买商品会有订单数据,个人信息会有个人的数据,成千上万的用户产生的数据会非常多,几十亿上百亿的数据量是非常可观的。
- 用户分布广泛、网络复杂 
互联网的应用不受地域限制,只要可以访问因特网,世界各地的人都可以访问一款应用,比如Facebook就是全球各个地方各个国家的人都会访问,Google的地图搜索也供世界各地的人使用,所以提升各个国家的用户的体验对互联网应用来说也是当务之急。
- 安全问题 
互利网应用暴露在因特网上,除了用户使用,也吸引了其他不法分子的目光,不法分子会利用网站的漏洞攻击网站,进行非法牟利,比如网络上的黑产,就是不法分子盯上了电商网站的漏洞,为自己牟利。黑客也会攻击网站,非法窃取网站的隐私数据,导致用户数据泄露,等等。这些都是信息安全的问题,假设你是用户,如果你使用的网站老是被攻击,老是有数据泄露问题,你还会放心的使用吗?所以维护好安全问题也是一大挑战。
- 渐进式发展 
互联网应用被设计出来,不是一蹴而就的,不是一开始上线的时候就是现在的这样,都是随着业务发展而逐渐迭代,逐渐演进的。系统架构也是根据业务的需求不断改造,为的就是支撑业务的发展,所以不同于传统企业系统,使用者都是内部员工,往往功能点都是一开始就规划好的。但互联网的系统,业务是快速发展的,往往今天的架构明天就不合适了,所以理解渐进式发展的特点,也有助于我们应对挑战。
二、应对高并发的挑战的两个技术方向
当系统需要处理的用户请求越来越多,需要支持的在线人数越来越多时,系统就要扩展处理能力,可以通过垂直伸缩和水平伸缩的方式
- 垂直伸缩 
垂直伸缩是指通过增加单台服务器的性能来提升处理能力。比如现在的服务器是4核,16G,可以处理500人同时在线。如果需要支撑1000人在线,那么可以把服务器升级到8核,16G,这样因为cpu的核数增加了,单位时间内,可以处理的请求数更多了,内存增加了,可以同时允许更多在线人数了。如果后续访问网站的人更多了,还可以再继续增加cpu核数,增加内存。垂直伸缩通过增加单台机器的硬件能力,来实现系统处理能力的扩展,做法简单,一开始人数不多的时候,效果还是比较明显的。但是垂直伸缩也不是万能的,越到后面,能提高的空间就越小了,因为单台服务器是有自己极限的,不可能无限制的往上面加cpu核数和内存。越到后面,成本越高,收益也越小。
- 水平伸缩 
针对垂直伸缩单台服务器硬件受限的问题,使用水平伸缩就没有这个问题。水平伸缩是指通过增加服务器数量来提升系统处理能力的。水平伸缩突破了单台服务器的硬件限制,基本上可以做到无限制的扩展。如果访问的人数变多了,单位时间内可以处理请求的人数也变多了,那么可以通过增加新的服务器来处理。如果人数越来越多,那么相应的,增加更多的服务器来解决。比如Google在全球就有数百万台服务器来处理每天多达几十亿次的请求,而且水平伸缩也不像垂直伸缩后面那样会有成本压力,基本上增加的服务器的数量和提高的系统处理能力的两者之间的曲线比较平滑。缺点就是水平伸缩提升了系统复杂度,使得整个系统的架构变得更加错综复杂,需要考虑服务器集群之间的协作,需要考虑各个服务器之间通信等问题,对设计分布式的系统有更高的要求。
三、互联网架构演进
- 第0阶段:最简单的互联网应用架构 

这个阶段的互联网应用就是一个单机应用,应用程序、文件系统、数据库都在单台服务器上,它们共用同一服务器的cpu,内存、磁盘、网卡,它们会相互争抢cpu内存磁盘网卡等资源,如果应用繁忙,会导致数据库性能下降,同样的,数据库繁忙也会导致应用性能下降。
- 第1阶段:应用数据分离 

这个阶段的架构是应用程序单独部署在应用服务器,文件系统单独部署在文件服务器上,数据库单独部署在数据库服务器上。这样做的好处是应用程序、文件、数据库没有共享同一个硬件资源,彼此之间也不会争抢cpu、内存等,处理能力大大提高了。如果应用程序繁忙,不会挤占数据库的资源,而且可以针对应用服务器,数据库服务器和文件服务器进行单独升级。
- 第2阶段:使用缓存改善系统性能 

这个阶段面临的挑战是为了加快应用程序处理的速度,对一些需要重复计算的数据,不需要每次都从数据库查询,而是先去缓存里面查找,如果缓存里面没有,然后再去数据库里面查询,把查询之后的结果放在缓存里面,下次请求可以直接从缓存里面拿。受限于单台服务器的内存资源,应用一般会把本地缓存和分布式缓存结合起来使用。缓存作为一种提高系统处理速度的手段,在这个阶段起到了重要的作用。
- 第3阶段:使用应用服务器集群提高并发处理能力 

这个阶段的显著特点是受限于单台应用服务器的硬件约束,应用程序的并发处理能力不高,为了提高应用程序的并发处理能力,通过水平扩展的方式,增加应用服务器的数量,从而可以处理更多的用户请求,满足更多的在线用户。应用服务器形成了集群,在集群之前,增加负载均衡服务器,用户的请求先通过负载均衡服务器,根据负载均衡算法,每个用户的请求最终都被分配到单台服务器并处理。每台应用服务器都可以访问文件服务器,数据库服务器和分布式缓存。
- 第4阶段:数据库读写分离 

随着用户访问的增多,尽管我们已经使用了分布式缓存,但还是会有相当一部分请求会直接命中数据库,单节点数据库会成为系统的性能瓶颈。数据库读操作只是查询数据库,而写操作需要更新记录,更新索引,产生日志等,比读操作耗时。而在这些数据库操作中,读操作又占了很大一部分,通过把数据库的读写操作分离,写操作都在主库,读操作都在从库,主库拥有最新的数据,从库的数据通过主从同步机制从主库同步过来,尽量保持最新。对于数据可以允许一定延迟的情况,等主库数据更新完之后,过一段时间,用户访问从库也能看到了,对于数据需要实时的情况,可以更新完主库再更新缓存。
- 第5阶段:使用反向代理和CDN加速 

这个阶段的架构变化在于利用CDN和反向代理加速网站的静态资源访问速度,CDN服务器是部署在电信运营商的机房里面的,可以把静态图片、css、js、视频等资源缓存在CDN服务器上,用户的请求第一时间会到达CDN服务器,如果正好有用户需要的资源,则直接访问,如果没有用户需要的资源,则请求会到反向服务器上,反向代理服务器上也会缓存静态资源,如果有,则直接访问,如果没有,则请求会到达应用程序来处理。当有新的资源需要更新时,可以把资源在CDN服务器和反向代理服务器上都先更新一下。
- 第6阶段:使用分布式文件系统和分布式数据库 

虽然通过数据库读写分离,缓解了数据访问压力,但是随着业务规模越来越庞大,单表的数据量已经非常大了,读写操作的性能还是很慢。这个时候,通过分库分表的方式,把数据分散到多台数据库服务器上,每一台服务器的数据量适中,读写操作的性能会有所提高。这个时候的数据访问模块就会根据分片算法,把用户的请求落在单台服务器上,整个数据库访问的设计会很复杂,因为数据分散了,如果要做汇总处理,往往很麻烦,需要单台数据库处理之后再汇总处理。分布式文件系统同样也是把文件分散到多台服务器上,通过数据访问模块的分片算法访问到具体的文件服务器。
- 第7阶段:使用NoSQL和搜索引擎 

随着网站的数据越来越多,海量的数据需要保存起来,传统的关系型数据库不能很好的存储海量数据,可以利用NoSQL服务器存储这些数据。NoSQL一般指非关系型的、分布式的数据存储,比如HBase,Hive等。同时,针对海量数据,也会有数据检索的需求,应用程序通过统一访问模块请求搜索引擎服务器,在海量的数据里面查询用户请求的数据,比如ElasticSearch,可以很好的支持海量数据查询。
- 第8阶段:业务拆分 

系统的业务越来越复杂,把所有的业务都放在同一个应用里面运营和维护也带来很多挑战,通过把业务拆分成一个一个相互独立的子业务系统,然后子业务系统之间通过消息队列的方式相互通信,降低耦合。每个自主业务系统都会拥有独立的域名,比如电商网站的商品浏览,订单,搜索,购物车都可以被视作一个一个独立的子业务系统,通过在首页上的菜单超链接整合在一起。通过业务拆分,降低单个应用的复杂度,每个子业务系统可以让独立的团队去运营和维护,也可以去单独演化。
- 第9阶段:微服务中台化 

随着子系统越来越多,每个子系统依赖的一些基本操作也都是类似的,比如商品浏览需要访问商品,订单也需要访问商品,搜索也需要访问商品。如果每个子系统都把访问商品的操作都放在自己系统里面,不仅会数据库连接浪费,或者数据库无法承受这么连接,还因为都需要维护同样的访问商品的业务逻辑,维护成本很高。通过把每个子系统共同依赖的服务抽出来当做公共的微服务,不仅节省了数据库资源,降低维护成本,而且以后如果需要开发新的子系统,可以直接调用已有的微服务,省去了很多开发成本。
- 第10阶段:大数据与智能化 

随着大数据和人工智能技术的使用,互联网系统会收集每个用户的数据,在移动端和浏览器端的埋点数据,挖掘用户存量的数据,利用爬虫系统获取一些其它网站的数据,把收集到的数据导入到大数据仓库里面,并利用大数据工具MapReduce、Hive、Spark等分析海量数据,获取用户的画像、特征等分析结果,并导入到其它数据库中,同时对于实时采集的数据会有Flink、Spark Streaming等实时处理,所有的结果会被其它应用系统、数据监控平台,运营决策系统等使用。大数据平台用来支撑系统的智能化,针对每个用户做到个性化推荐,个性化服务等。
四、互联网架构模式
类似于设计模式,架构模式是指针对一些重复发生的架构问题,总结出来的用于解决这些问题的方式方法。架构模式是被实践证明的,可以帮助我们更好的设计系统。
- 分层 
分层是把系统按照横向的维度,分成几个独立的模块。比如我们可以把系统分为存储层、应用层、视图层,存储层是数据库系统,用来保存数据库,应用层是系统后台业务处理的系统,视图层则是前端显示的模块,比如移动端App、浏览器都是视图层。每个层级逐级调用,便于开发和维护。
- 分割 
分割是把系统按照纵向的维度,分成几个独立的子系统。每个子系统都有自己的存储层、应用层、视图层,每个子系统可以单独开发、部署、维护。子系统之间可以通过消息中间件等进行通信。通过分割,整个大系统分成小系统,提高了网站的并发处理能力。
- 分布式 
分布式通过增加多台服务器,增加总的cpu、内存、网卡、磁盘等资源,提高了整体的并发处理能力,系统之间通过远程调用的方式协同工作。
- 集群 
集群是指把多台服务器当成一个整体对外提供服务,集群中的每台服务器和其它服务器没有什么差别,通过负载均衡技术,用户的请求会被集群中的一台服务器处理。
- 缓存 
缓存是为了提高处理请求的速度,一般是把数据存放在速度最快的地方。比如CDN缓存是把网站静态资源放在电信运营商的机房,这里一般是请求最先到达的地方。反向代理是把资源存放在反向代理服务器上,可以避免直接请求应用服务器。本地缓存是把服务器内存作为缓存的手段,因为内存访问速度比访问数据库快得多,可以把从数据库返回的结果放在内存中,以便下次请求可以直接使用。远程缓存是指Redis、Memcache等分布式缓存服务器,因为数据存放在远程服务器的内存里面,访问速度也非常的快。
- 异步 
异步因为把请求中比较耗时或者用户不关心的操作放在异步过程中处理,提供了系统的响应速度,提升了用户体验。同时,如果网站访问量过高,通过把请求暂存在消息队列中,异步处理请求,起到了削峰填谷的作用。
- 冗余 
因为网站需要7*24小时对外提供服务,为了系统的高可用,一般会采用冗余备份的方式,多配置几台服务器,维护数据的多个副本,以便在应用服务器宕机时,通过启用备用服务器,网站仍然可以对外提供服务。
- 自动化 
因为系统变得越来越复杂,模块越来越多,集群规模越来越庞大,以前的手动发布已经不合时宜了,采用自动化发布、部署应用,提高开发、部署的效率。
- 安全 
互联网应用暴露在网络上,所有人都可以访问到,有可能会有不法分子会攻击网站,窃取用户信息、因此隐私数据比如用户名密码、身份证等信息需要做加密保存。还需要防止SQL注入、XSS工具对系统安全的影响,过滤垃圾信息、非法请求。
五、如何衡量一个系统的架构设计
- 高性能 
高性能作为互联网应用的一个重要指标,直接影响用户使用系统的体验。用户的忍耐都是有限度的,如果网站访问速度奇慢无比,估计也不会有多少用户喜欢了,直接就导致用户流失,影响公司的发展。高性能体现在方方面面,比如首页加载要快,订单处理速度要快,报表数据处理要快,等等,也可以从多个方面优化,比如从CDN优化、从反向代理服务器优化、从数据库查询优化、从缓存优化,所有的这些都可以提高系统的性能。
- 高可用 
高可用直接影响系统的使用,服务器硬件会不可避免的宕机,如果单台服务器上的话,碰到宕机情况,用户就不能使用了,如果经常这样,用户肯定是不会再光顾。通过增加多个服务器节点,拷贝多份数据,万一某些服务器挂机,其他服务器可以顶替,使系统还可以正常使用。
- 可伸缩 
可伸缩是指是否可以简单的通过增加服务器的方式,提高系统的处理性能。如果现有集群不能再增加新的节点,则意味着伸缩性差,或者增加新的节点会有很高的成本,会涉及到大量的数据迁移,则伸缩性也不够好。加入集群的方式越简单,越不涉及过多的操作,则伸缩性越好。
- 可扩展 
可扩展是指当系统需要增加新的功能时,是否可以简单的增加新的模块或者新的服务来实现,不涉及到修改现有的代码或者涉及到少量的修改,而且新功能对系统现有的功能影响小。如果架构越是可扩展的,则开发和维护成本就越低,因为过多的改动已有的系统功能会导致大量的测试,直接影响开发效率。可扩展架构的主要手段是事件驱动架构和分布式服务。
- 安全 
互联网因为暴露在网络环境下,所有人都可以访问,一个安全的架构可以有效防止系统被攻击、防止用户数据泄露,也不会因为系统设计的漏洞被不法分子抓住而造成巨大的损失。可靠的安全架构还应该可以有效的应对潜在的危险和监控系统的运行状态,还能自动过滤有害信息和自我保护。
六、互联网架构技术一览
- 前端架构 
App及Web开发技术
浏览器及Http优化技术
CDN
动静分离
图片服务
反向代理
DNS
- 网关及应用层架构 
网关架构
负载均衡
动态页面静态化
业务拆分
- 服务层架构 
微服务框架
分布式消息队列
分布式缓存
分布式一致性服务
- 存储层架构 
分布式文件
分布式关系数据库
NoSQL数据库
- 后台架构 
大数据平台
搜索引擎
推荐引擎
数据仓库
- 运维与安全 
数据采集与展示
数据监控与报警
攻击与防护
数据加密与解密












 
    
评论