大型网站技术架构 – 第二节读书笔记

  • 2018-07-17
  • 0
  • 0

作者:黄志成

博客:地址

今天北京倾盆大雨~太可怕了;还好下班回来即时.不然就成落汤鸡了.

回来好好看书.今天继续阅读《大型网站技术架构》一书.

网站架构模式

本节主要介绍的是网站架构模式.那什么是模式呢?

每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样,你就能一次又一次使用该方案而不必做重复工作.

模式的重要性就是可复用性.

互联网产品不是随便复制成功的.创新的产品更能为用户创造价值。但是网站的架构却有一些共同的模式,我们可以掌握大型网站架构的一般思路和解决方案,以指导我们架构设计.

下面说说几种常见的架构模式

分层

分层是企业应用系统中最常见的一种架构模式,将系统横向维度上切分成几个部分,每个部分负责相对比较单一的职责,然后通过上层对下层的依赖和调用组成一个完整的系统.

分层在计算机世界中无处不在,网络有七层通信协议;计算机硬件、操作系统、应用软件也可以看做一种分层结构。作为程序员的我们也有最熟悉的MVC分层.

image

Controller层: 应用程序中处理用户交互的部分

View层: 负责业务视图的展示.

Model层:是应用程序中用于处理应用程序数据逻辑的部分,通常是读取数据

这是web应用最常用的一种模式.

MVC 分层有助于管理复杂的应用程序,因为您可以在一个时间内专门关注一个方面。例如,您可以在不依赖业务逻辑的情况下专注于视图设计。同时也让应用程序的测试更加容易。

通过分层,可以更好地将一个庞大的软件系统切分成不同的部分,便于分工合作开发和维护。当然上面分层还是最基础的.还可以继续细分.

比如下面的一个分层架构:

image

开发接口: 用来对外提供接口,http访问.

请求处理层: 此层主要用来接收参数,和参数校验

业务逻辑层: 相对具体的业务逻辑服务层。业务逻辑层不用关心数据从哪来的,怎么来的.只需要调用数据平台层就可以获取到数据.

数据平台层: 通用业务处理层,它有如下特征:1. 对第三方平台封装的层,预处理返回结果及转化异常信息;2. 对Service层通用能力的下沉,如缓存方案、中间件通用处理;3. 与DAO层交互,对多个DAO的组合复用。

数据持久层(DAO层):数据访问层,与底层 MySQL、Oracle、Hbase 进行数据交互。

数据源: 数据源就是Mysql、Redis、file中的数据。

分层架构有一些挑战,就是必须合理规划层次边界和接口,在开发过程中,严格遵循分层架构的约束,禁止跨层次的调用(业务逻辑层直接调用数据源中数据)及逆向调用(数据持久层调用业务逻辑层的东西).

分层结构对网站支持高并发和分布式方向至关重要。因此在网站规模还很小的时候就应该采用分层的架构,这样将来网站做大时才能有更好的应对.

分割

如果说分层是将软件在横向方面进行切分,那么分割就是在纵向方面对软件进行切分.

网站越大,功能越复杂,服务和数据处理的种类也越来越多,将这些不同的功能和服务分割开来,包装成高内聚低耦合的模块单元,一方面有助软件的开发和维护;另一方面,便于不同模块的分布式部署,提高网站并发能力.

比如一个商城程序,它的主要压力一定在,订单处理和商品上面,我们可以把它的订单模块和商品模块拆分,然后搭建在不同服务器.降低再一台服务器上的压力.从而实现高并发.

分布式

对于大型网站,分层和分割的一个主要目的是为了切分后的模块便于分布式部署,即将不同模块部署在不同服务器上,通过远程调用协同工作.

分布式是一把双刃剑.好在可以使用更多的资源完成任务,可以无限的扩容下去.

同样更多的服务器会带来一些问题,分布式之间需要通过网络交互数据,这会对性能造成很大影响;其次,服务器越多出现宕机的概率就越大.一台服务器宕机可以会造成其他服务也出现问题.另外,数据在分布式的环境中保持数据一致也非常困难,分布式事务也难以保证.这对网站的正确性和业务流程可能会有很大影响.分布式也会使网站更加错综复杂,开发和管理维护的困难.

做架构一定要量力而行!不要为了分布式而分布式.

集群

使用分布式虽然已经将分层和分割后的模块独立部署,但对于用户访问集中的模块(比如首页),还需要将独立部署的服务器集群化,即多台服务器部署相同应用构成一个集群,通过负载均衡设备共同对外提供服务.

可能有些人对分布式和集群的概念还是有些模糊.

总结就是:分布式是指将不同的业务分布在不同的地方。 而集群指的是将几台服务器集中在一起,实现同一业务。

分布式中的每一个节点,都可以做集群。 而集群并不一定就是分布式的。

缓存

缓存就是将数据放在距离计算最近的位置加快处理速度.缓存是改善性能的第一手段.在复杂的网站中,缓存无处不在.

CDN: 内容分发网络,部署在距离终端用户最近的网络服务商,用户的网络请求总数先到达他的网络服务商那里,在这里缓存一些静态资源,可以更快的速度返回给用户。

反向代理: 反向代理属于网站前端架构的一部分,部署在网站前端,当用户请求网络数据中心时候,最先访问的就是反向代理服务器.这里缓存的资源无需将请求继续转发给应用服务器就能返回数据.

本地缓存:在应用服务器本地内存中缓存着热点数据.

分布式缓存: 大型网站的数据量非常庞大,即使只缓存一小部分也不是单机能承受的.这时候就需要分布式缓存.

异步

计算机软件发展的一个重要的目标和驱动力就是降低软件耦合,事务之间直接关系越少,彼此影响就小,越是可以独立发展。

异步:业务直接数据传递而不再通过同步调用,而将一个业务操作分成多个阶段,每个阶段通过共享数据的方式异步进行协作.

image

异步架构就是典型的生产者消费者模式,两者间不存在直接调用,只要保持数据结构不变,彼此功能可以随意变化而不互相影响,这对网站扩展非常便利.除外异步消息队列还要如下特性

提高系统可用性。 如果消费者服务器发生故障,消息会在消息队列中堆积,生产者可用继续处理业务请求,系统总体无故障.

加快网站响应速度。 某些数据不需要立刻返回,这样可以将它加入消息队列延迟处理.

消除并发高峰。 将突发的访问请求数据加入消息队列.等待消费者服务器依次处理.

异步方式处理业务可能会对用户体验、业务流程造成影响,需要网站设计方面的支持.

冗余

网站需要7*24小时连续运行,但服务器可能随时出现故障,特别是服务器规模比较大的时候,出现某台服务器宕机是必然事件.这时候数据冗余就必然重要。

访问量很小的服务也至少部署两台服务器构成一个集群就是为了防止发生单点故障.

数据库需要定期备份,存档保存,实现冷备份外,为了保证在线业务高可用,还需要对数据库进行主从分离,实现数据热备份.

自动化

在无人值守的情况下网站可以正常运行,一切都可以自动化是网站理想状态.目前大型网站自动化架构设计主要在发布运维方面.

发布对网站是头等大事.许多故障发生在发布.基本上每逢发布必加班.甚至通宵.

通过减少人工干预实现自动化代码管理,自动化测试,自动化安全监测,到最后自动化部署.

上线后,还需要自动化监控,自动化报警,自动化降级....

这个是需要很强大的技术支持。

安全

如果写出的程序漏洞百出,那将是一个巨大的隐患.如果你的商城可以被黑客0元购物.那么你的商户和你的资金将得不到保障.

所以网站安全也是一个大型网站架构中必不可少的一部分.

小结

在程序设计与架构领域,模式正变得越来越受人关注,许多人寄希望通过模式一劳永逸解决自己的问题.正确使用模式可以更好利用业界和前人思想,用更少时间开发出更好的系统,但模式受其场景的限制.不恰当的使用会画虎不成反类犬.

永远记住 架构中没有银弹.好的设计绝对不是模仿,不是生搬硬套某个模式,而是对问题的深刻理解与创新.

山寨与创新的最大区别不在于是否抄袭,是否模仿,而在于对问题和需求是否真正理解与把握.

架构是一门艺术.学无止境!通过阅读前辈们的书籍.使我更加充实.

写于 2018年07月17日00:30

评论

还没有任何评论,你来说两句吧