大型网站技术架构-第七篇-随需应变:网站的可扩展架构

1周前 (2019-12-09)     作者:LG     分类:读书     阅读次数:     评论(0)    文章页统计代码

■ 正文

既然我们知道网站不停上新产品是其生存的本能,谁能更快更好地推出更多的新产品,谁就活得更滋润,那么工程师就要做好准备应付这种局面。马克思的劳动价值理论告诉我们,产品的内在价值在于劳动的时间,劳动的时间不在于个体付出的劳动时间,而在于行业一般劳动时间,资本家只会为行业一般劳动时间买单,如果你的效率低于行业一般劳动时间,对不起,请你自愿加班。反之,如果你有一个更具有扩展性的网站架构,可以更快速地开发新产品,也许你也享受不了只上半天班的福利,但是至少在这个全行业加班的互联网领域,你能够按时下班,陪陪家人,看看星星。


1) 扩展性(Extensibility):指对现有系统影响最小的情况下,系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更,应用之间较少依赖和耦合,对需求变更可以敏捷响应。它是系统架构设计层面的开闭原则 (对扩展开放,对修改关闭),架构设计考虑未来功能扩展,当系统增加新功能时,不需要对现有系统的结构和代码进行修改。

2) 伸缩性(Scalability):指系统能够通过增加(减少)自身资源规模的方式增强(减少)自己计算处理事务的能力。如果这种增减是成比例的,就被称作线性伸缩性。在网站架构中,通常指利用集群的方式增加服务器数量、提高系统的整体事务吞吐能力。

3) 事件驱动架构(Event Driven Architecture):通过在低耦合的模块之间传输事件消息,以保持模块的松散耦合,并借助事件消息的通信完成模块间合作,典型的EDA架构就是操作系统中常见的生产者消费者模式。在大型网站架构中,具体实现手段有很多,最常用的是分布式消息队列

4) 巨无霸系统拆分原则:将模块独立部署,降低系统耦合性。拆分可以分为纵向拆分和横向拆分两种:

a) 纵向拆分:将一个大应用拆分为多个小应用,如果新增业务较为独立,那么就直接将其设计部署为一个独立的Web应用系统。

b) 横向拆分:将复用的业务拆分出来,独立部署为分布式服务,新增业务只需要调用这些分布式服务,不需要依赖具体的模块代码,即可快速搭建一个应用系统,而模块内业务逻辑变化的时候,只要接口保持一致就不会影响业务程序和其他模块。


5) 大型网站分布式服务的需求与特点

a) 负载均衡:对热门服务,比如登录服务或者商品服务,访问量非常大,服务需要部署在一个集群上。分布式服务框架要能够支持服务请求者使用可配置的负载均衡算法访问服务,使服务提供者集群实现负载均衡。

b)      失效转移:可复用的服务通常会被多个应用调用,一旦该服务不可用,就会影响到很多应用的可用性。因此对于大型网站的分布式服务而言,即使是很少访问的简单服务,也需要集群部署,分布式服务框架支持服务提供者的失效转移机制,当某个服务实例不可用,就将访问切换到其他服务实例上,以实现服务整体高可用。

c) 高效的远程通信:对于大型网站,核心服务每天的调用次数会达到数以亿计,如果没有高效的远程通信手段,服务调用会成为整个系统性能的瓶颈。

d)      整合异构系统:由于历史发展和组织分割,网站服务可能会使用不同的语言开发并部署于不同的平台,分布式服务框架需要整合这些异构的系统。

e) 对应用最少侵入:网站技术是为业务服务的,是否使用分布式服务需要根据业务发展规划,分布式服务也需要渐进式的演化,甚至会出现反复,即使用了分布式服务后又退回到集中式部署,分布式服务框架需要支持这种渐进式演化和反复。当然服务模块本身需要支持可集中式部署,也可分布式部署。

f)  版本管理:为了应对快速变化的需求,服务升级不可避免,如果仅仅是服务内部实现逻辑升级,那么这种升级对服务请求者而言是透明的,无需关注。但如果服务的访问接口也发生了变化,就需要服务请求者和服务提供者同时升级才不会导致服务调用失败。企业应用系统可以申请停机维护,同时升级接口。但是网站服务不可能中断,因此分布式服务框架需要支持服务多版本发布,服务提供者先升级接口发布新版本的服务,并同时提供旧版本的服务供请求者调用,当请求者调用接口升级后才可以关闭旧版本服务。

g)      实时监控:对于网站应用而言,没有监控的服务是不可能实现高可用的。分布式服务框架还需要监控服务提供者和调用者的各项指标,提供运维和运营支持。


6) 开放平台架构原理

a)API接口:是开放平台暴露给开发者使用的一组API,其形式可以是RESTful、WebService、RPC等各种形式。

b)协议转换:将各种API输入转换成内部服务可以识别的形式,并将内部服务的返回封装成API的格式。

c) 安全:除了一般应用需要的身份识别、权限控制等安全手段,开放平台还需要分级的访问带宽限制,保证平台资源被第三方应用公平合理使用,也保护网站内部服务不会被外部应用拖垮。

d) 审计:记录第三方应用的访问情况,并进行监控、计费等。

e) 路由:将开放平台的各种访问路由映射到具体的内部服务。

f)  流程:将一组离散的服务组织成一个上下文相关的新服务,隐藏服务细节,提供统一接口供开发者调用。


除非注明,发表在“石马人山的博客”的文章『大型网站技术架构-第七篇-随需应变:网站的可扩展架构』版权归LG所有。 转载请注明出处为“本文转载于『石马人山的博客』原地址http://longlonggo.com/html/1///150/178/464.html
文章页分享代码