您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 
 订阅
互联网公司分布式系统架构演进之路
 
 
  1077  次浏览      18 次
 2022-8-22
 
编辑推荐:
本文主要介绍了互联网公司分布式系统架构演进之路 。希望对你的学习有帮助。
本文来自于51CTO,由火龙果软件Linda编辑、推荐。

介绍

分布式和集群的概念经常被搞混,现在一句话让你明白两者的区别。

分布式:一个业务拆分成多个子业务,部署在不同的服务器上

集群:同一个业务,部署在多个服务器上

例如:电商系统可以拆分成商品,订单,用户等子系统。这就是分布式,而为了应对并发,同时部署好几个用户系统,这就是集群

1 单应用架构

2 应用服务器和数据库服务器分离

单机负载越来越来,所以要将应用服务器和数据库服务器分离

3 应用服务器做集群

每个系统的处理能力是有限的,为了提高并发访问量,需要对应用服务器做集群

这时会涉及到两个问题:

负载均衡

session共享

2 负载均衡就是将请求均衡地分配到多个系统上,常见的技术有如下几种

DNS

DNS是最简单也是最常见的负载均衡方式,一般用来实现地理级别的均衡。例如,北方的用于访问北京的机房,南方的用户访问广州的机房。一般不会使用DNS来做机器级别的负载均衡,因为太耗费IP资源了。例如,百度搜索可能要10000台以上的机器,不可能将这么多机器全部配置公网IP,然后用DNS来做负载均衡。

Nginx&LVS&F5

DNS是用于实现地理级别的负载均衡,而Nginx&LVS&F5用于同一地点内机器级别的负载均衡。其中Nginx是软件的7层负载均衡,LVS是内核的4层负载均衡,F5是硬件做4层负载均衡,性能从低到高位Nginx<LVS<F5

下图形象的展示了一个实际请求过程中,地理级别的负载均衡和机器级别的负载均衡是如何分工和结合的,其中粗线是地理几倍的负载均衡,细线是机器级别的负载均衡,实线代表最终的路由路径

session共享就是用户在A服务器登录,结果查看购物车时,请求发送到了B服务器,因此用户的session存在A服务器上,所以当请求发送到B服务器上时,会认为用户没有登录

简单说一下session和cookie的交互过程,有想深入了解的看推荐阅读,假设用户在A服务器登录,tomcat会在HttpServletReponse中添加一个cookie,key为JSESSIONID,当用户第二次访问的时候会带上这个cookie,而tomcat会根据这个JSESSIONID找到HttpSession,怎么找到呢?因为tomcat中有这样一个ConcurrentHashMap,key为JSESSIONID value为 Session对象,以后会详细讲这块,要想真正理解清楚,内容也挺多的。

所以当应用服务器只有一个时,登录一般都是写成如下:

@RequestMapping(value = "login", method = RequestMethod.POST)
// ServerResponse是小编封装的一个返回对象
public ServerResponse<User> login(String username, String passwrod, HttpSession session) {
ServerResponse<User> response = userService.login(username, passwrod);
// 登录成功,将用户信息放到session中
if (response.isSuccess()) {
session.setAttribute(Const.CURRENT_USER, response.getData());
}
return response;

 

查看购物车时,写成如下

@RequestMapping(value = "list", method = RequestMethod.GET)
public ServerResponse<CartVo> list(HttpSession session) {
User user = (User)session.getAttribute(Const.CURRENT_USER);
if (user == null) {
// session中没有有用户信息,需要登录
return ServerResponse.errorCodeMsg(ResponseCode.NEED_LOGIN.getCode(), ResponseCode.NEED_LOGIN.getDesc());
}
return cartService.list(user.getId());
}

 

目前解决session跨域共享问题有如下几种方式

session sticky

将请求都落到同一个服务器上,如Nginx的ip hash

session replication

session复制,每台服务器都保存一份相同的session

session 集中存储

存储在db、 存储在缓存服务器 (redis)

cookie (主流)

将信息存在加密后的cookie中

4 数据库高性能操作

搭建数据库主从集群,实现数据库读写分离,改善数据库负载压力

数据库读写分离的基本实现如下:

数据库服务器搭建主从集群,一主已从,一主多从都可以

数据库主机负责读写操作,从机只负责读操作

数据库主机通过复制将数据同步到从机,每台数据库服务器都存储了所有的业务数据

业务服务器将写操作分给数据库主机,将读操作分给数据库从机

实现方式

读写分离需要将读/写操作区分开来,然后访问不同的数据库服务器;分库分表需要根据不同的数据访问不同的数据库服务器,两者本质上都是一种分配机制,即将不同的SQL语句发送到不同的数据库服务器。

读写分离,包括后面要提到的分库分表的实现方式有两种:

程序代码封装

中间件封装

程序代码封装指在代码中抽象一个数据访问层来实现读写分离,分库分表

中间件封装指的是独立一套系统出来,实现读写分离和分库分表操作,如我们熟悉的MySQL Router和Mycat等

5 引入搜索引擎来查询

传统的关系型数据库通过索引来达到快速查询的目的,但是在全文搜索的业务场景下,索引也无能为力,主要体现在如下几点:

全文搜索的条件可以随意排列组合,如果通过索引来满足,则索引的数量会非常多

全文搜索的模糊匹配方式,索引无法满足,只能用like查询,而like查询是整表扫描,效率非常低

6 增加缓存

为了应对流量持续增加,必须增加缓存

常见的方式有如下几种:

Redis与Memcached

以我们常见的Mybatis为例,很容易和Redis与Memcached整合起来,缓存已经查询过的SQL,因为Mybatis知道自己不擅长缓存,所以提供了接口让这些缓存工具进行整合

CDN

CDN是为了解决用户网络访问时的“最后一公里”效应,本质上是一种“以空间换空间”的加速策略,即建内容缓存在离用户最近的地方,用户访问的是缓存的内容,而不是站点实时的内容。

7 分库分表

读写分离分散了数据库读写操作的压力,但没有分散存储压力,当数据量达到千万甚至上亿条的时候,单台服务器的存储能力会成为系统的瓶颈。常见的分散存储的方法有分库和分表两大类

业务分库

业务分库指的是按照业务模块将数据分散到不同的数据库服务器。例如,一个简单的电商网站,包括商品,订单,用户三个业务模块,我们可以将商品数据,订单数据,用户数据,分开放到3台不同的数据库服务器上,而不是将所有数据都放在一台数据库服务器上

当然业务分库也会带来新的问题:

join操作问题:业务分库后,原本在同一个数据库中的表分散到不同数据库中,导致无法使用SQL的join查询

事务问题:原本在同一个数据库中不同的表可以在同一个事务中修改,业务分库后,表分散到不同数据库中,无法通过事务统一修改

成本问题:业务分库同时也带来了成本的代价,本来1台服务器搞定的事情,现在要3台,如果考虑备份,那就是2台变成6台

分表

表单数据拆分有两种方式,垂直分表和水平分表

垂直分表:垂直分表适合将表中某些不常用且占了大量空间的列拆分出去。如上图的nickname和description字段不常用,就可以将这个字段独立到另外一张表中,这样在查询name时,就能带来一定的性能提升

水平分表:水平分表适合表行数特别大的表,如果单表行数超过5000万就必须进行分表,这个数字可以作为参考,但并不是绝对标准,关键还是要看表的访问性能

水平分表后,某条数据具体属于哪个切分后的子表,需要增加路由算法进行计算,常见的路由算法有

范围路由:选取有序的数据列(例如,整型,时间戳等)作为路由条件,不同分段分散到不同的数据库表中。以最常见的用户ID为例,路由算法可以按照1000000的范围大小进行分段,1-999999放到数据库1的表中,1000000-1999999放到数据库2的表中,以此类推

Hash路由:选取某个列(或者某几个列组合也可以)的值进行Hash运算,然后根据Hash结果分散到不同的数据库表中。同样以用户Id为例,假如我们一开始就规划了10个数据库表,路由算法可以简单地用user_id%10的值来表示数据所属的数据库表编号,ID为985的用户放到编号为5的子表中,ID为10086的用户放到编号为6的子表中。

配置路由:配置路由就是路由表,用一张独立的表来记录路由信息,同样以用户ID为例,我们新增一张user_router表,这个表包含user_id和table_id两列,根据user_id就可以查询对应的table_id

8 应用拆分/微服务

随着业务的发展,业务越来越多,应用的压力越来越大。工程规模也越来越庞大。这个时候就可以考虑将应用拆分,按照领域模型将我们的商品,订单,用户分拆成子系统。

这样拆分以后,可能会有一些相同的代码,比如订单模块有对用户数据的查询,用户模块中肯定也有对用户数据的查询。这些相同的代码和模块一定要抽象出来。这样有利于维护和管理。这时可以将模块变为一个个服务,模块之间互相调用来获取数据,系统就变成一个微服务了。

服务拆分以后,服务之间的通信可以通过RPC技术,比较典型的有:Webservice、Hessian、HTTP、RMI等。如当前的Dubbo和Spring Cloud都是目前比较流行的微服务框架,2者之间还是有很多区别的,以后分享。

   
1077 次浏览       18
相关文章

中央计算的软件定义汽车架构设计
汽车电子控制系统中的软件开发过程
一文读懂汽车芯片-有线通信芯片
OTA在汽车上有哪些难点痛点?
相关文档

汽车设计-汽车的整体结构及动力系统
自动驾驶汽车软件计算框架
SysML在汽车领域的应用实践
电子电气架构-大陆汽车系统架构平台
相关课程

AutoSAR原理与实践
功能安全管理体系(基于ISO26262)
MBSE(基于模型的系统工程)
基于SOA的汽车电子架构设计与开发

最新活动计划
MBSE(基于模型的系统工程)4-18[北京]
自然语言处理(NLP) 4-25[北京]
基于 UML 和EA进行分析设计 4-29[北京]
以用户为中心的软件界面设计 5-16[北京]
DoDAF规范、模型与实例 5-23[北京]
信息架构建模(基于UML+EA)5-29[北京]
 
 
最新文章
在EA中内嵌文档- Artifact
EA中模型视图
EA中的实体关系图
使用EA进行风险建模
EA中的项目词汇表
EA的模型导出或导入csv文件
自定义表格(Custom Table)在EA中的使用
Gap Analysis Matrix(差距分析矩阵)
更多...   
MBSE工具
MBSE平台
建模工具 EA
模型库-Model Center
需求管理-ReqManager
自动建模-Modeler
多级仿真-Sys Simulator
代码工程-Code Engineer
文档生成器-DocGenerator
更多...   
成功案例
广汽研究院 SysML+EA+软件分析设计
高合汽车研发部门 建模工具EA、WebEA、学习视频
国汽智联 建模工具EA、模型库、WebEA和iSpace
亿咖通 MBSE工程体系与工具链咨询
中航无人机 MBSE工具链
吉利汽车 购买EA工具
华科汽车零部件 购买EA工具
东风岚图汽车 购买EA工具 以及EA定制开发
更多...