架构师训练营w4-作业

一个典型的大型互联网应用系统使用了哪些技术方案和手段，主要解决什么问题？请列举描述。

一个典型的大型互联网应用，从技术角度看，最大的特点就是高并发、大流量了。例如Google这种巨型互联网产品，每秒光处理空格数据量就超过8GB以上。淘宝双十一、12306春运、以及微信同时在线人数都无一例外具备大流量，高并发的特点。



那么，在这样一个大型互联网应用系统的演进过程中，都用了哪些技术方案和手段来应对高并发、大流量情况的。这些方案和手段主要解决什么问题的呢？



应用数据分离



在应用系统初期，往往是将应用、数据库以及文件存储等放到一台机器上。随着上线正式运行一段时间后，单机性能急剧下降。

这时候采用将应用与数据分离的技术方案改善架构，如下图所示：

应用，数据库，资源文件各自在单独的服务器上运行。

这种架构改造方案主要是解决单机性能瓶颈问题。将服务器职责划分，易于后续扩展。比如后续数据库服务器压力变大。我们可以单独改善数据库服务器的性能。没错，最先出问题的可能就是数据库。

缓存技术

经过一定时间的运行以及业务量的上升。应用没次业务都去请求数据库，大大影像前端页面响应速度，降低用户体验。

因此可以在应用与数据库之间架设缓存，避免没次请求都要到数据库中，以达到缓解数据库压力的目的。架构演进图如下：

一般情况下可以采用memcache来做本地缓存。家里条件好的也可以使用Redis来做分布式缓存。到目前我们保住了我们的数据库服务器。

集群技术

好了，业务发展的太好了。好在我们将应用与数据分开了，现在发现应用出问题了。

如果我们使用java开发的，不出意外应用是部署在Tomcat中。这家伙并没有那么高的性能，扛不住太大压力。再加上代码写的也不咋样。应用服务器扛不住了。怎么办？集群。

我们在最前端架设负载均衡服务器，后端将应用集群部署。通过负载均衡策略，将请求均衡的分发的后端服务器上。

负载均衡服务器一版情况可以采用Nginx或者LVS。家里条件好可以选购商用负载。

现在好了，原本一个人干不过来的活，被分配到多人手中，顿时轻松了很多。而且，应用服务器可以横向扩展，随着业务量的变化还可以做到弹性伸缩。

数据库读写分离技术

老哥终于挺不住了，业务请求的不断增多，应用服务器可以弹性伸缩。数据库服务器不行，还是单机。终于到了极限，资源占用率高，请求变慢，性能急剧下降。怎么办？读写分离。

部署数据库服务器，该数据库服务器的特点是只从主库同步数据，只对外提供查询服务。

上层应用通过技术手段对读写请求分别路由到主从数据库上，进而缓解了数据库压力。

至此，这个架构应该算上中等规模的互联网应用，家里条件不好的还不一定搞得起。

CDN静态资源加速技术

网站越来越大了，用户分步在大江南北。如果我们的机房在华北地区，那么对于华中、华南的用户就不友好了，因为网络区域显示，网速会变得很慢，华南地区用户访问网站事响应速度很慢，用户不断抱怨。怎么办？CDN加速。

CDN是构建在现有网络基础之上的智能虚拟网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。

假设上CDN服务器后，大江南北的百姓喜笑开颜。

分布式文件系统与分布式数据库

随着用户量不断增多，业务压力越来越大，基于木桶原理，总是存在短板。总是有优化的空间。

目前看数据库与文件系统都可进行优化，将数据库与文件系统改造成分布式的。进而提升高性能与高稳定性。

NoSQL数据库技术与搜索引擎技术

NoSQL数据库种类繁多，代表性强的如Redis，MongoDB。以Redis为例，其超高的读写速度引人注目。

对应用进行改造时，可以使用Redis存放热点数据，进一步缓解数据库的压力。以为最先容易出问题而改造成本最高的就是数据库服务器。



搜索引擎技术技术的代表是Lucene。我们可以基于它做我们应用的全文搜索引擎。

业务拆分

随着业务不断发展，代码也是不断的膨胀。再加上原班人马陆续被替换，传承有做的不是很好。种种原因融合在一起，在应对新业务或老业务重构时，对业务进行拆分是明智的选择。





微服务与中台建设

转眼间已经来到了2020年，随着技术的不断发展，云计算，微服务，中台，边缘计算，人工智能等新的词汇不断冲击着你腐朽的脑壳。你似乎有些觉醒，你决定要改变了，彻底改变。

将所有应用都迁移到阿里云上。

购买RDS，Redis，HBase，LBS，ECS，WEB防火墙，安骑士，态势感知，短信网关，容器服务，镜像仓库，等等云计算服务。

来做微服务吧，将这种微小的，易于维护的，可快速发布的应用上云吧~~

后续

后续怎么弄让用户告诉你吧~~