静态网站特点,网站换友链平台,用博客网站做淘宝客,网站后端用什么语言文章目录系统大致架构可扩展性负载均衡器与会话保持引入冗余增强系统可用性缓存减轻数据库压力异步处理参考系统大致架构
当一个用户请求从客户端出发#xff0c;经过网络传输#xff0c;达到 Web 服务层#xff0c;接着进入应用层#xff0c;最后抵达数据层#xff0c;它…
文章目录系统大致架构可扩展性负载均衡器与会话保持引入冗余增强系统可用性缓存减轻数据库压力异步处理参考系统大致架构
当一个用户请求从客户端出发经过网络传输达到 Web 服务层接着进入应用层最后抵达数据层它所途径的过程如下 对应到系统设计的逻辑层 运作机制如下 1、客户端查DNS得到服务对应的IP地址可能指向位于Web服务之前的负载均衡器也可能是CDN就近提供对象存储中的静态资源 2、发向Web服务的请求被负载均衡器(如反向代理)按照既定策略分给相应的Web服务器进入应用层 3、请求到达应用层后经过Service Discovery、Service Mesh等服务查询机制找到目标微服务开始处理请求 4、数据请求会通过一系列读写操作转移到数据层异步的操作还会进入消息队列排队但最终都会抵达数据层 5、对热点数据的请求会被数据库之前的缓存层挡下其余的落到数据库可能是经过分库分表、反范式优化并由复制机制保证数据一致性的SQL数据库也可能是查询性能更好的Nosql数据库抑或是对象存储来保存数据。
接下来的系统设计主要就是围绕这几个关键的逻辑组件展开。
可扩展性
可扩展性意味着能够通过向系统添加资源的方式应对不断增加的工作量。而加资源有两种方式
纵向扩展Vertical scaling即提升单机配置对单台机器加内存、处理器、硬盘等硬件资源。投入足够多的预算就能砸出一台配置豪华的服务器横向扩展Horizontal scaling即加机器数量上从一台扩展到多台多服务器形成拓扑结构。投入足够多的预算就能拥有一个机房甚至遍布全球的数据中心 对于系统设计而言可扩展性要求系统能够将加入进来的更多资源如多核、多机利用起来。 机器由一台变成多台之后面临的最大问题是资源分配如何充分利用这些机器即如何均衡负载
负载均衡器与会话保持
负载均衡器Load Balancer负责把用户请求分发到多个服务器上具体的公网 Load Balancer 根据路由规则分发入站 HTTP 请求决定把数据包实际发送给哪个内网服务器。常见的策略是基于负载情况分发、轮流均分、基于资源依赖情况分发。不建议用 DNS 来充当负载均衡器因为操作系统以及应用层的 DNS 缓存会破坏这种轮流均分的机制。另一方面不同类型的服务对资源的依赖情况带宽、存储、计算能力等可能不一样所以也可以采用专用服务器并根据资源依赖情况分发比如对 gif、jpg、image、video 等使用不同的专用服务器并通过子域名等方式来区分 会话保持 加一层 Load Balancer 解决了资源分配的问题但又带来了一个新问题前后两个请求可能被负载均衡器转发到不同的服务器上如果这两个请求有关联比如登录和下单前置的状态就会丢失用户刚登录完点击下单接着可能又要求登录 一种解决办法是粘滞会话Sticky sessions把相关联的请求转发给同一台服务器 比如在 Cookie 中带上服务器的标识信息之后的一系列请求都转给那台服务器但 Cookie 可能会被禁用因此一般会综合使用多种方式来保持会话 另一种方案是把 Session“外包”出去存放到公共的地方供其它服务器共享访问 每台服务器都包含完全相同的代码库不在本地光盘或内存中存储任何与用户相关的数据如会话或个人资料图片。会话需要存储在所有应用服务器都可以访问的集中数据存储中。 至此我们增加了一些机器并通过一个负载均衡器让多台机器共同分担运转起来了看起来一切都很完美……那么如果这个负载均衡器 down 掉了呢
引入冗余增强系统可用性
引入负载均衡器之后所有请求都要先经过负载均衡器负载均衡器就成为了网络拓扑结构中脆弱的单点一旦发生故障身后的所有服务器就都无法访问了。 为了避免单点故障Single Point of Failure负载均衡器同样需要引入冗余比如使用一对儿负载均衡器一般有两种故障转移Fail-over模式
主动-被动Active-passive主动的工作被动的备用主动的 down 掉后被动的上主动-主动Active-active同时工作一个 down 掉之后不影响 无论采用哪种工作模式引入冗余都能缩短宕机时间提升系统可靠性与可用性
理论上有了可靠的负载均衡机制我们就能将 1 台服务器轻松扩展到 n 台然而如果这 n 台机器仍然使用同一数据库的话很快数据库就会成为系统的性能瓶颈和可靠性瓶颈 如法炮制我们可以扩展数据库的处理能力多加几个库即引入冗余一般有两种模式
主从复制主库直接读写从库在主库收到查询时执行相同的查询。如果主库 down 掉了就在从库里面提升一个作为主库主主复制都可以写写操作也会被复制到另一个库中 数据库引入冗余之后甚至还能对多个从库进行负载均衡尤其适用于读密集的场景 以及按内容特点分区存储Partitioning 将姓名以 A-M 开头的数据存放到左边的几个数据库N-Z 开头的存放到右边
同时也可以通过分库分表Sharding、反范式化Denormalization、SQL 调优SQL tuning等方式优化查询
缓存减轻数据库压力
尽可能减少数据库操作比如在 Web 服务与数据之间增加一层内存缓存查询时优先走缓存缓存中没有才从数据库中取。 一般有两种缓存模式
缓存查询结果缓存对象 缓存所有查询结果最大的问题在于数据发生变化后很难判定缓存是否过期
在缓存复杂查询时很难删除缓存的结果谁没有。
当一段数据发生更改例如表单元格时需要删除可能包含该表单元格的所有缓存查询。而缓存对象是指缓存根据原始数据组装出的数据模型比如一个 Java 类实例优势在于获知数据变化之后能够丢弃与之具有逻辑关联的数据对象从而解决缓存过期的难题。 至此我们已经自下而上地讨论了包括硬件资源、数据库、缓存在内的可扩展性问题那么Web 服务自身应该如何扩展
异步处理
对于 Web 服务而言提升可扩展性的主要途径是将耗时的同步工作改成异步处理从而允许将这些工作“外包”给多个 Worker 去做或者提前完成能够预知的部分.
参考
1、http://gotocon.com/dl/goto-aar-2012/slides/MartinThompson_ItsAllANumbersGameTheDirtyLittleSecretOfScalableSystems.pdf 2、http://www.ayqy.net/blog/scalability-in-the-real-world/ 3、https://github.com/donnemartin/system-design-primer/blob/master/README-zh-Hans.md
