经验分享：资深架构师教你什么是网络应用架构.docxVIP

经验分享：资深架构师教你什么是网络应用架构 01 从一个场景开始 以上的架构图是对 Storyblocks 业务架构的一个很好的概括。对于那些相对缺乏经验的 web 开发者，或许你会觉得这个架构有些复杂。没关系，在讲解相关组件的具体业务细节之前，我们先举个例子，帮你更容易地理解 Storyblocks 的业务架构。 先从一个场景开始：用户用谷歌搜索 「美丽的浓雾和林间的阳光」 。首个结果正好出自 Storyblocks：一个知名的图片和矢量图资源网站，用户点击该条结果，浏览器重定向到该图片的所在的详情页面。 这个场景背后，用户浏览器向 DNS 服务器发送请求，查询 Storyblocks 的域名信息，然后发送访问请求。访问请求首先经过负载均衡器，负载均衡器会从十多台运行网站服务的网络服务器选择任意一台，将请求发送到这台服务器进行处理，网络服务器先从缓存服务器查询图片的详情信息，然后从数据库获取图片的其他相关信息。 我们注意到这张图片的色彩配置信息还没被计算出来，于是服务器将一个新的色彩配置任务推送到任务队列，我们的任务队列服务器将异步地处理图片的色彩配置信息计算，一旦计算完成，便将配置信息更新到数据库中。 下一步，服务器将图片标题作为关键词，向全文检索服务发送查询请求以寻找相似图片。此时用户登入他的 Storyblocks 账户，相应地，服务器从账户服务中获取用户账户信息。 接下来，我们将这个页面浏览事件加载到 data firehose(AWS 推出的流数据装载服务) 以记录到云存储系统，并最终存储到数据仓库，便于分析师分析使用并帮助解答业务问题。 服务端将视图呈现为为 HTML 页面并经由负载均衡器，返回用户的浏览器客户端。这个页面同时包含存储在云存储系统的 Javascript 和 CSS 代码文件，云服务器直接连接到 CDN 集群，内容也经由 CDN 分发，用户浏览器访问 CDN 集群并获取内容。 最终，浏览器渲染页面使用户可以浏览阅读。 接下来，我将带你遍历每个组件，并做简要说明和介绍，帮助你形成一个相对准确的概念模型，以便于理解网络架构和组件间的交互。我仍将遵循已经分享的文章中给出的一些实践建议，这些建议基于我在 Stroyblocks 的业务经验，具有一定参考价值。 02 网络架构诸组件 1. DNS 服务 DNS (Domain Name System)代表 「域名系统」，这是实现互联网相互连接的核心技术。DNS提供从域名 (例如 ) 到 IP 地址 (20) 的最底层的键值对查询服务，事实上，计算机基于网站的 IP 地址路由到合适的服务器。用电话号码比喻的话：域名和 IP 地址的关系，类似于联系人姓名和号码的关系。 正如你需要通过电话簿来查询特定联系人的电话号码，你同样需要通过 DNS 来查询指定域名的 IP 地址，所以你完全可以把 DNS 理解为互联网的电话号码簿。 我们以后会深入介绍关于 DNS 的详细原理，现在进入下一个话题。 2. 负载均衡 在深入介绍负载均衡之前，我们需要先行解释应用架构的水平拓展和垂直拓展。 你肯定会好奇这两个概念的含义和区别：简单来说，水平拓展是指你向资源池增加更多机器设备，而垂直拓展则意味着增加更多算力资源(CPU，内存)到现有机器设备。对于 Web 开发，水平拓展常常是最好的选择。 毕竟，所有事物都可能中断，服务器有时崩溃，网络会降速，甚至整个数据中心也会偶尔断线。如果要防止出错，除了保持简单，我们别无选择。使用服务器集群可以帮你有效应对突发情况，增强业务的健壮性和容错性，确保应用持续稳定地运行。 其次，水平拓展允许你将后端服务 (网络服务器，数据库，应用服务) 的不同组件分配在不同服务器，借此你可以高效地调用后端服务的不同组件。 最后，垂直拓展很容易遇到规模瓶颈，谷歌的搜索服务平台是一个相当典型的案例，这个场景也同时适用于 Storyblocks 这样的中小型公司，举例来说，我们在任意时刻都运行着 150 到 400 个 AWS EC2 实例，如果要通过垂直拓展模式提供同等算力，很难想象我们需要使用何种级别和规模的计算机设备（估计得使用超算了）。 现在我们回到负载均衡器，它们是实现业务水平拓展的重要部分，它们将接收的访问请求路由到互为备份的应用服务器集群中的任意一个，并将应用服务器的响应返回到客户端。任何一个应用服务器的处理方式都完全相同，通过这种方式，负载均衡器将访问请求均匀地分派到不同的服务器以防止服务器过载。 负载均衡器的业务原理相当简单，但是要深入理解，就涉及到很多复杂的概念，这些更加复杂的概念，我们将在以后进行讲解。 3. Web 应用服务器 从抽象角度来说，Web 应用服务器的作用是这样的：它们被用来执行诸如处理用户请求和将 HTML 返回用户浏览器等核心业务逻