做微网站公司淘宝店铺设计

当前位置： 首页 > news >正文

做微网站公司,淘宝店铺设计,网站设计方案图,微信开放平台登陆可扩展性#xff0c;指的是网站的架构设计能够快速适应需求的变化#xff0c;当需要增加新的功能实现时#xff0c;对原有架构不需要做修改或者做很少的修改就能够快速实现新的业务需求。 从这个定义中#xff0c;我们很容易就可以得出衡量网站可扩展性设计优秀与否的主要标…       可扩展性指的是网站的架构设计能够快速适应需求的变化当需要增加新的功能实现时对原有架构不需要做修改或者做很少的修改就能够快速实现新的业务需求。 从这个定义中我们很容易就可以得出衡量网站可扩展性设计优秀与否的主要标准就是增加新功能的时候对原有系统的影响是否足够小。 当今的商业环境决定了网站新功能开发与上线的时间周期必须非常短如果每次添加新功能都需要对原有系统进行大量修改从而还会牵连出更多测试工作的话那么你的竞争力就会被大打折扣用一个不太恰当的比喻就是直接“输在了起跑线上”。 其实添加新功能时必须要对系统进行大幅度修改的原因是系统架构设计上的耦合性。那么有什么“好的”架构设计方案可以使得我们添加新功能的时候只需对原有系统做少量修改甚至完全不需要修改吗 咋一听起来这就像“又要马儿跑又要马儿不吃草”。但其实不是的。我们往往可以通过架构上的设计优化来达到事半功倍的效果。 为了帮助你理解可扩展性先看一个案例。 网站可扩展性架构设计的案例 假设你现在为了实时监控服务器的健康状态需要为网站添加一个实时收集服务器端监控指标的功能此时最直接的方案就是用代码去实现对每一个监控指标的收集然后将所有的这些代码集成在一起形成一个可执行程序运行在服务器端后台。 这样的设计固然简单直接而且也能实现所有的功能需求收集各种监控指标但是当你需要收集一个新的监控指标时就不得不更新整个可执行程序了。如果你需要经常添加新的监控指标的话那么这样的设计就不能满足可扩展性的要求了。 我们希望的是当增加新的监控指标的时候原有的系统不需要做任何修改甚至可以做到实时添加全新的监控指标。为了达到这个目的现有的其他方案都不能满足或者不容易满足这个要求所以我们就必须要在架构设计上做些文章了。 我们可以把对每一个监控指标的代码实现直接打包成一个个的可执行监控子程序比如收集CPU使用率的程序A、收集内存使用率的程序B等然后运行在服务器后台的监控主程序通过调用这些子程序比如程序A和B来实现所有的监控需求。 这时再增加新的监控指标时原有系统就不需要做任何改动只需要独立实现新的监控子程序然后以配置文件的形式“告诉”主程序新添加的监控子程序的路径即可。这也就实现了系统的可扩展性。 接下来我们再一起回到网站的可扩展性设计上来。其实提升网站可扩展性性的核心就是降低系统各个模块和组件之间的耦合。耦合程度越低各个模块和组件的复用可能性就越大系统的可扩展性也会越好。 从现在来看实现网站可扩展性架构的主要技术手段包括事件驱动架构和微服务架构。 微服务架构从根本上改变了网站的架构形式带来可扩展性便利的同时还带来了很多其他优秀的特性。在微服务架构下一个大型复杂软件系统不再由一个单体组成而是由一系列的微服务组成。其中每个微服务可被独立开发和部署各个微服务之间是松耦合的。每个微服务仅专注于完成一件任务并要很好地完成该任务。 在微服务架构下当网站需要增加新功能时我们除了可以添加新的业务逻辑外还可以利用原本已经存在的微服务来构建新的功能。由于服务和服务之间是相互隔离的并且单个服务还可以被其他多个服务复用所以系统的可扩展性会比较好。 事件驱动架构与消息队列 事件驱动架构设计的出发点源于这样一个事实如果系统的各个模块之间的协作不是通过直接的调用关系来实现的那么系统的可扩展性就一定会更好。问题是系统的各个模块间的协作如何才能不基于调用关系呢 答案就是事件消息。系统各个模块之间只是通过消息队列来传输事件消息而各模块之间并没有直接的调用关系、保持松散的耦合关系。 事件驱动架构最典型的一个应用就是操作系统中常见的生产者和消费者模式将其应用到网站设计中就是分布式消息队列。 分布式消息队列同样采用了生产者和消费者模式 消息的发送者负责将消息发布到消息队列中也就是“生产者”另外系统中会有一个或者多个消息接收者订阅消息订阅目的是为了获取消息并进行处理这里的消息订阅者其实就是“消费者”。消息接收者发现消息队列中有新的消息后就会立马对其进行处理。 可以看到在这种模式下消息的发送者和接收者之间并没有任何直接的联系是松耦合的。它们的协作是通过消息队列这个“中间人”进行的。消息的发送者将消息发送至消息队列后就结束了对消息的处理而消息的接收者只是从消息队列中获取消息进行后续的处理并不需要知道这些消息从哪里来因此可以很方便地实现高可扩展性。 所以采用这种模式的话当网站需要增加新功能的时候只要增加对应的新模块再由对此模块感兴趣的“消费者”进行订阅就可以实现对原有系统功能的扩展了而对原本的系统模块本身并没有影响。 此时消息队列的架构如图1所示。 图1 消息队列的原理图 引入了消息队列后我们不仅可以提高系统的可扩展性还可以再一定程度上改善网站架构的高性能、高可用性和可伸缩性。 从性能方面来看消息发送者不需要等接收者实际处理完成后才返回也就是从原本的同步处理变成了异步处理所以用户会感知到网站性能的提升。从高可用方面来看假如消息的接收者模块发生了短时间的故障此时并不会影响消息发送者向消息队列中发送消息等到消息接收者模块恢复后可以继续后续的处理只要这段时间内消息队列本身没有被塞满而出现消息丢失的情况。从整体角度看系统并不会感知到消息接收者模块曾经发生过短暂故障也就相当于保证了系统的高可用。从可伸缩性方面来看消息队列的核心其实就是一个无状态的存储。所以当系统需要能够保留更多的消息时我们通过简单地增加存储空间就可以实现。尤其是大规模的电商网站来更会将消息队列扩展成为分布式消息队列集群来实现消息队列的可伸缩性。 引入消息队列后测试人员需要额外关注的点 现在你应该已经掌握了消息队列的基本原理以及在网站架构中的用法。接下来我们再一起看看消息队列对测试的影响以及我们在测试时需要特别关注哪些点。 这里我把测试人员需要额外关注的点归纳为了以下几点 从构建测试数据的角度来看为了以解耦的方式测试系统的各个模块我们就需要在消息队列中构造测试数据。这也是为什么很多互联网的自动化测试框架中都会集成有消息队列写入工具的主要原因。从测试验证的角度来看我们不仅需要验证模块的行为还要验证模块在消息队列中的输出是否符合预期。为此互联网的自动化测试框架中也都会集成消息队列的读取工具。从测试设计的角度来看我们需要考虑消息队列满、消息队列扩容等情况下系统功能是否符合设计预期。除此之外我们还需要考虑某台消息队列服务器宕机的情况下丢失消息的可恢复性以及新的消息不会继续发往宕机的服务器等等。 总结 在这篇文章中分享了网站架构知识中的可扩展性。 可扩展性指的是网站的架构设计能够快速适应需求的变化当需要增加新功能时我们只要对原有架构进行少量修改甚至不用修改就能快速实现新的业务需求。 从技术实现上来看消息队列是实现可扩展性的重要技术手段之一。其基本核心原理是各模块之间不存在直接的调用关系而是使用消息队列通过生产者和消费者模式来实现模块间的协作从而保持模块与模块间的松耦合关系。 引入消息队列后测试数据的创建和测试结果的验证工作都需要通过读写消息队列来完成。同时我们还要考虑到消息队列满、消息队列扩容以及消息队列服务器宕机情况下的系统功能验证。这几个点就是测试人员需要额外关注的点了。