Browsed by
日期:2020年10月26日

千万级用户的大型网站,应该如何设计其高并发架构?

千万级用户的大型网站,应该如何设计其高并发架构?

閱讀本文約花費: 10 (分鐘)目录 (1)单块架构 (2)初步的高可用架构 (3)千万级用户量的压力预估 (4)服务器压力预估 (5)业务垂直拆分 (6)用分布式缓存抗下读请求 (7)基于数据库主从架构做读写分离 (8)总结 (1)单块架构 一般一个网站刚开始建立的时候,用户量是很少的,大概可能就几万或者几十万的用户量,每天活跃的用户可能就几百或者几千个。 这个时候一般网站架构都是采用单体架构来设计的,总共就部署3台服务器,1台应用服务器,1台数据库服务器,1台图片服务器。 研发团队通常都在10人以内,就是在一个单块应用里写代码,然后写好之后合并代码,接着就是直接在线上的应用服务器上发布。 很可能就是手动把应用服务器上的Tomcat给关掉,然后替换系统的代码war包,接着重新启动Tomcat。 数据库一般就部署在一台独立的服务器上,存放网站的全部核心数据。 然后在另外一台独立的服务器上部署NFS作为图片服务器,存放网站的全部图片。应用服务器上的代码会连接以及操作数据库以及图片服务器。如下图所示: (2)初步的高可用架构 但是这种纯单块系统架构下,有高可用问题存在,最大的问题就是应用服务器可能会故障,或者是数据库可能会故障 所以在这个时期,一般稍微预算充足一点的公司,都会做一个初步的高可用架构出来。 对于应用服务器而言,一般会集群化部署。当然所谓的集群化部署,在初期用户量很少的情况…

Read More Read More

深入解读Service Mesh背后的技术细节

深入解读Service Mesh背后的技术细节

閱讀本文約花費: 14 (分鐘)一、Service Mesh是Kubernetes支撑微服务能力拼图的最后一块 在上一篇文章为什么 kubernetes 天然适合微服务中我们提到,Kubernetes是一个奇葩所在,他的组件复杂,概念复杂,在没有实施微服务之前,你可能会觉得为什么Kubernetes要设计的这么复杂,但是一旦你要实施微服务,你会发现Kubernetes中的所有概念,都是有用的。 在我们微服务设计的是个要点中,我们会发现Kubernetes都能够有相应的组件和概念,提供相应的支持。 其中最后的一块拼图就是服务发现,与熔断限流降级。 众所周知,Kubernetes的服务发现是通过Service来实现的,服务之间的转发是通过kube-proxy下发iptables规则来实现的,这个只能实现最基本的服务发现和转发能力,不能满足高并发应用下的高级的服务特性,比较SpringCloud和Dubbo有一定的差距,于是Service Mesh诞生了,他期望讲熔断,限流,降级等特性,从应用层,下沉到基础设施层去实现,从而使得Kubernetes和容器全面接管微服务。 二、以Istio为例讲述Service Mesh中的技术关键点 就如SDN一样,Service Mesh将服务请求的转发分为控制面和数据面,因而分析他,也是从数据面先分析转发的能力,然后再分析控制面如何下发命令。今天这篇…

Read More Read More

浅谈领域模型

浅谈领域模型

閱讀本文約花費: 10 (分鐘)|01 领域模型是什么 领域模型是什么?一句话:“经济基础决定上层建筑”中的“经济基础”,是帮助理解复杂业务领域问题的基石。 有人说:“领域模型是一个商业概念,同行业的企业,一定有内在的共性,是帮助系统分析人员认识现实业务的工具。”领域,即边界的意思,有了清晰的边界,协作才有了利益的基础;模型,即知识体系,深入理解了业务知识,开发才不会走过多的弯路。一般意义上的领域模型是面向软件工程领域的,而现实意义的领域模型则包含了商业模式等广义上的概念。 很多人一上来理解领域驱动设计(DDD),基本都是一头雾水,因为模型设计的初衷并不是围绕性能、架构、分层等软件概念展开的,而是从边界、内聚等抽象概念开始讲起。理解领域模型,并不是通过技术的思维来学习,而是通过不断地实践过程来训练自我的思维意识,进而彻底形成结构化与面向对象的思维方法论。 领域模型并不能直接带来收益,只是辅助我们去理解正在做的事情。 引用百度的说法,“领域模型是对领域内的概念类或现实世界中对象的可视化表示。又称概念模型、领域对象模型、分析对象模型。它专注于分析问题领域本身,发掘重要的业务领域概念,并建立业务领域概念之间的关系。”总结一下,就是“准确描述问题,清晰描述方案”。 如果说软件开发的本质,是从“问题空间”到“解决方案空间”的转化,那么“领域模型”,就是“解决方案空间”的架构,通过抽象的模型,…

Read More Read More

Scroll Up