架构
文章平均质量分 66
永远sayYES
这个作者很懒,什么都没留下…
展开
-
PUSH和PULL的模式的特性
PUSH和PULL模式的特性对比。原创 2022-09-20 17:03:56 · 147 阅读 · 0 评论 -
容器开放接口规范(CRI OCI)比较
CRI VS OCI一、CRI - Container Runtime Interface高层次的容器运行时抽象接口,比如怎么从仓库拉取镜像,怎么管理镜像。containerd来自Docker,实现了CRI,接受上游的命令(比如Docker,K8S调度),拉取镜像,并管理镜像,然后转交给底层的运行时(比如runC)CRI-O来自Red Hat, IBM, Intel, SUSE,openshift使用的是CRI-O。CRI 接口定义// Runtime service defines the原创 2021-08-20 13:13:26 · 2182 阅读 · 0 评论 -
系统架构思路
性能提高机器的配置三大分离让系统可以水平扩展a. 接入层的DNS轮询b. 数据库的水平切分,分库分表稳定性 / 高可用垂直拆分,不至于一挂全挂反向代理(把服务集群化)+反向代理层的VIP+Keepalived...原创 2020-08-18 17:54:51 · 114 阅读 · 0 评论 -
TCP接入的负载均衡和高可用架构
一、架构图客户端请求通过web-server的getTcpIP接口来获取可用的tcp服务IP列表,可以实现负载均衡,水平扩容web-server和tcp服务器保持心跳,把down掉的服务拿掉,保证高可用。通过web-server主动去拿getStatus,而不是通过tcp服务器的report,体现的是服务架构不能反向依赖耦合;因为web-server是一个子系统,主系统不应该依赖于衍生出来的下级系统。类似的还有在CDN架构中,源不能把源文件推给镜像,因为正常是镜像依赖于源,如果源在依赖于镜像的话,原创 2020-07-17 17:38:34 · 465 阅读 · 0 评论 -
接入层的负载均衡、高可用、扩容
一、接入层的负载均衡利用nginx的反向代理来实现站点层web-server的负载均衡,负载均衡算法有:随机,轮询,静态权重,一致性hash等。接入层的负载均衡实现是依赖于LVS的负载均衡(操作系统级别,比nginx应用层性能更好)使用F5(硬件级别,性能比LVS更好)二、接入层的高可用不管使用LVS,还是F5,虽然性能比nginx好很多,但是依然存在单点问题。需要通过keepalived + VIP 来保证高可用三、接入层的扩容虽然现在实现了高可用,负载均衡,但是还是受限于一台原创 2020-07-15 18:18:03 · 580 阅读 · 1 评论 -
如何保证Session一致性
如何保证Session一致性?一、方案Session同步法多台web-server互相同步数据,缺点是水平扩展受限,因为每台web-server都是存储所有的session客户端存储法session存储到浏览器cookie中,每个客户端只要存储一个用户的数据了。缺点是占用外网带宽、大小受限(因为cookie有大小限制)反向代理hash一致性四层Hash和七层Hash都可以做,保证一个用户的请求落在一台web-server上,缺点是不能保证高可用,如果一台web-server down机了,上原创 2020-07-15 17:41:16 · 476 阅读 · 0 评论 -
应用架构种类 - 集中式架构,垂直拆分,分布式服务,服务治理,微服务
比较参考https://blog.csdn.net/sinat_42338962/article/details/84642665原创 2020-08-24 09:39:05 · 174 阅读 · 0 评论 -
应用架构种类 - 垂直拆分
如何快速解耦:垂直拆分业务代码数据库研发团队原创 2020-08-18 17:40:55 · 301 阅读 · 0 评论 -
应用架构种类 - 微服务架构
一、What微服务架构是指,组成一个整体系统是由许多不同的子系统构成,这些子系统独立存在,而又会互相调用。一个典型的微服务系统有以下几个组成部分:注册中心配置中心网关各个独立的子模块二、使用场景数据量千万级别,访问量千万级别三、优势复用性,消除代码拷贝专注性,防止复杂性扩散解耦和,消除公共库耦合高质量,SQL稳定有保障易扩展,消除数据库耦合高效率,调用方研发效率提升四、粒度统一服务层一个子业务一个服务一个数据库一个服务一个接口一个服务最佳实践是:一个子业务原创 2020-08-24 15:27:41 · 253 阅读 · 0 评论 -
中间件 - 搜索引擎架构细节
搜索引擎架构 + 检索需求方案演进一、宏观全网搜索引擎,三大模块:spider,index,rankspider + index:工程系统,各大搜索引擎比如百度和谷歌,都是差不多的。rank:业务策略系统,这个不同的搜索引擎不一样。搜索结果的好坏,核心在rank二、实时搜索引擎架构核心:索引分级dump & merge实施要点:实时定点写实时分段读异步导出合并三、微观正排索引:url_id快速找到list<item>倒排索引:分词item快速原创 2020-08-19 17:54:36 · 399 阅读 · 0 评论 -
中间件 - MQ架构细节
一、使用MQ的时机不使用:强依赖结果使用:场景一:数据驱动的任务依赖场景二:上游不关心执行结果,比如发帖子后要增加积分,或者统计之类的操作场景三:上游关心执行结果,但执行时间很长二、MQ消息必达怎么做到?消息落地超时,重传,确认三、幂等生产者:MQ-client生成inner-msg-id,保证上半场幂等。上半场:inner-msg-id,这个ID全局唯一,业务无关,由MQ保证。消费者:业务发送方带入biz-id,业务接收方去重保证幂等。2. 下半场:unique-b原创 2020-08-18 15:29:49 · 147 阅读 · 0 评论 -
中间件 - RPC内核架构
一、WhatRPC:远程过程调用二、Why屏蔽底层细节,让系统专注于业务逻辑,而非实现细节三、How序列化与反序列化:首先要搞定网络传输,必须要把对象序列化为字节流。方案一:自描述,比如xml,json等文本协议方案二:序列化协议,性能更好,通信内容都是干货,不像文本协议会有很多其他干扰杂质信息在里面,比如xml的标签等。序列化协议设计,考虑因素:解析效率、压缩率,传输有效性、扩展性,兼容性、可读性,可调试性、跨语言、通用性常用的序列化方法(协议):xml/json、protobuf、原创 2020-08-26 16:08:15 · 309 阅读 · 0 评论 -
缓存设计 - 进程内缓存
一、What将一些数据缓存在站点,或者服务的进程内,这就是进程内缓存。可以缓存json数据、html页面、对象。二、Why速度更快,少了一次网络请求(比如请求redis)节省内网带宽,少了一次网络请求(比如请求redis)三、How比如Java可以通过带锁的map来实现进程内缓存。又或者,可以使用第三方库,例如leveldb。使用场景:只读的数据。极其高并发,如果透传后端压力极大的场景。例如,秒杀业务,并发量极高,需要站点层挡住流量,可以使用内存缓存。一定程度上允许数据不一致业原创 2020-09-03 18:12:57 · 222 阅读 · 1 评论 -
缓存设计 - 缓存误用
误用一:把缓存作为服务于服务之间数据传递的媒介服务1和服务2约定好key和value,通过缓存传递数据;服务1将数据写入缓存,服务2从缓存读取数据,达到两个服务通信的目的。存在问题:数据管道,数据通知场景,MQ更加合适:思想是让专业的软件干专业的事情,nginx做反向代理,db做固话,cache做缓存,mq做通道多个服务关联同一个缓存实例,会导致服务耦合:a. 两个服务要约定好key的格式,value的格式,要保证两个服务的redis的IP和相关配置一致,如果一方改动,另外一方也要改动,原创 2020-09-04 13:10:06 · 91 阅读 · 0 评论 -
缓存设计 - 互联网最佳实践Cache Aside Pattern
WhatCache Aside Pattern翻译过来是旁路缓存方案的经验实践,这个实践分为读实践、写实践。How读实践:先读缓存,再读数据库如果cache hit,则直接返回cache数据如果cache miss,则访问db,并将数据set回缓存,然后返回。写实践:先操作数据库写,再淘汰缓存(这里淘汰缓存是删除,而不是更新)Why写实践中,Cache Aside Pattern为什么是淘汰缓存,而不是更新缓存?答:如果是更新缓存,在并发写时,可能出现数据不一致。如上图原创 2020-09-04 14:37:53 · 343 阅读 · 1 评论 -
缓存设计 - 一致性优化
What一致性是指数据库和缓存里的数据是一样的,如果出现两者不一样,就说出现了一致性问题。一致性优化是指怎么消除一致性问题,或者出现了一致性问题怎么去发现并解决。Why如果数据库和缓存不一致,会导致系统出现BUG,尤其是一些关键性的数据,比如余额。所以在一些不能容忍不一致的场景,是一定要消除不一致的问题。为什么会出现数据不一致?数据库主从不一致导致的数据库缓存不一致。淘汰缓存失败导致的数据库缓存不一致。参考《缓存设计 - 互联网最佳实践Cache Aside Pattern》中章节原创 2020-09-04 16:08:41 · 198 阅读 · 0 评论 -
缓存设计 - 并发更新的坑
What并发更新的坑指在并发更新缓存的时候,会出现并发更新的异常问题。导致与预期结果不一致,有的甚至会导致应用短时间不可用。比如微信里面可以根据appId 和 appSecret来获取access-token,这个access-token是微信接口访问的凭证,有效期两个小时,一般会保存到缓存。常见实现方式如下:(对应下面case1和case2)获取access-token,如果存在则调用接口如果不存在,则调用微信接口获取access-token,并缓存进redis,继续请求。实现方式二:(对原创 2020-09-09 14:25:51 · 238 阅读 · 0 评论 -
缓存设计 - Redis vs Memcache
What我们在做缓存设计的时候,需要选型哪一种缓存,现在市面上主流的有两种缓存中间件。一个是Memcache,一个是后起之秀Redis。Why选一个合适的中间件是非常重要的,不仅避免后期更换中间件带来的风险,而且合适缓存的会更好更快的完成任务。How比较表格如下:场景一:只有KV存储,数据量非常大,并发量非常大的业务,并且值都是小于1M的,并且无需持久化,则选用Memcache其他场景:其他场景大都选Redis,比如以下场景复杂数据结构持久化只读场景需要固化(即重启后,数据可以自己加原创 2020-09-10 14:14:26 · 74 阅读 · 0 评论 -
数据库设计 - 读性能提升
一、What:读性能指服务层读取数据库数据的性能,通常读取性能指标有sql查询QPS、sql查询响应时间。二、Why:为什么要提升读性能呢?因为大部分的互联网产品都是读多写少,所以最容易碰到的场景就是数据库读遇到瓶颈,所以解决数据库的读性能是首当其冲的。三、How:方法论:a. 优秀的表设计b. 冗余多台c.具体方案:...原创 2020-08-27 13:48:21 · 252 阅读 · 0 评论 -
数据库设计 - 垂直拆分
一、What垂直拆分是指把原来属于一个大表的字段,拆分成两个及以上表的字段,就像用刀垂直的砍了一下一个表,分成了多个表一样。二、Why垂直拆分的目的有二:减小表的容量通过减小行的大小,内存可以缓存更多行,从而提高缓存命中率,进而提高查询效率和速度。三、How垂直拆分的步骤:把表的字段分为两种类型,一种类型是字段长度小并且经常访问的字段,另外一种就是所有其他的,包括长度大但是经常访问以及不经常访问的字段。把第一种类型的字段建立一张独立的表。把其他类型的字段建立一张,或者多张独立的表。原创 2020-08-27 14:05:31 · 403 阅读 · 0 评论 -
数据库设计 - 高可用
一、What数据库的高可用是指数据库的读和写都是高可用的,任何一台读或者写服务器挂掉,都不会导致数据库的读写服务异常。二、Why提高系统的整体稳定性,和可用性。三、How方法论:冗余 + 故障自动转移。带来的新问题:数据一致性的问题。读库高可用:增加读库的节点,由上游的连接池来完成高可用。写库高可用:Keepalived + VIP的方式,缺点是只有50%的资源利用率双主同时对外提供写服务,双主之间双向同步 。并由上游的连接池来完成高可用。...原创 2020-08-27 14:17:29 · 228 阅读 · 0 评论 -
数据库设计 - 主从一致性
一、What主从一致性是指主库和从库在某一时刻数据可能会不一致。二、Why因为主从分组架构中,从库是需要时间来同步主库的数据库的,所以在某一时刻数据可能会有差别。比如主库0时刻修改了一条记录,500毫秒后才会同步到从库,那么从0时刻至500毫秒时刻主从的数据是不一致的,如果此时刚好有一个查询打到从库,则读到的是旧数据。三、How方案一:忽略不计如果业务侧是可以忍受读到短时间的一个脏数据的(通常只要用户刷新一下就是正确数据),那么忽略不计其实是最经济实惠的方式,只要业务允许,那么我们的架构也可原创 2020-08-27 14:41:45 · 970 阅读 · 0 评论 -
数据库设计 - 主主一致性
一、What在双主或者多主的情况下,主与主之间需要同步,在高并发的情况下,可能会出现同步失败的现象。那么此时就出现了主与主之间不一致的问题。二、Why那么为什么会出现主主不一致呢,也就是说为什么主与主之间会同步失败呢?通常是主主同步时主键冲突引起的,比如说主库使用的是自增id,如果同时来了两个请求分别到数据库主A和数据库主B,那么两者都各自增了1,比如是4,那么主A会同步主A的id为4的记录给主B,主B页会同步主B的id为4的记录给主A,产生了主键冲突,导致数据丢失。三、How方案一:数据库的自增原创 2020-08-27 15:05:59 · 261 阅读 · 0 评论 -
数据库设计 - 扩展性
一、What数据库模块可变更的能力叫做数据库扩展性。比如以下三个场景:底层的表结构变更:比如新增两个字段。因为线上数据量一般都是比较大的,如果直接ALTER TABLE会锁表,线上服务会不可用。水平分库的个数变化:比如两个水平分库变更为三个水平分库底层存储介质变换:比如mongodb修改为mysql二、Why数据库扩展性是指随着产品的迭代,数据库可能也需要迭代变更。三、How方案一:离线迁移数据,数据库升级期间服务不可用。适用场景1、2、3。发通告要升级服务停止服务数据变更恢复原创 2020-08-27 18:17:22 · 2772 阅读 · 0 评论 -
数据库设计 - 反范式冗余
What大学里面学习数据库的时候,要求都是要按照三范式设计。但是在互联网高并发大数据量的场景下,往往要反范式设计。Why因为反范式的好处是可以通过冗余存储来减少计算。How引入一个例子:订单业务举例订单业务Order(oid, info_detail)//订单主表T(buyer_id, seller_id, oid)//买家,卖家关系表数据量大怎么办?水平切分如何水平切分?如何满足查询?Order -> oidT -> buyer_id, seller_id?订单主原创 2020-09-14 10:41:33 · 275 阅读 · 0 评论 -
快速提升性能 - 三大分离架构设计
随着系统的用户和访问量越来越多,系统可能会出现性能瓶颈,怎么才能快速提升系统性能呢?答案就是三大分离架构设计一、读写分离指的是数据库的读写分离,解决的是数据库的读瓶颈,这个在互联网的场景中最常见。注意要区别于水平切分,水平切分是解决“数据库数据量大”的问题二、动静分离动静分离,指把页面分为静态页面和动态页面,分别使用不同的技术来加速。因为静态文件速度快是几毫秒级别,而动态页面比较慢是几十毫秒至几百毫秒级别,差距很大。把HTML, CSS, JS, 图片等资源文件单独分开。把动态页面静态化,原创 2020-07-17 18:16:03 · 303 阅读 · 1 评论 -
架构案例 - Feed业务架构设计实践
一、WhatFeed:订阅源经典场景,比如微博,Twitter,Facebook等社交网站,朋友圈等等特点是单人写,多人读数据:关系、粉丝、发布的feed消息难点:自己的主页是别人发布的feed组成,当并发量高的情况下(比如郭德纲发了一条feed),如果设计的不好,那么会造成粉丝拉取主页很慢二、How拉模式(读扩散):适合数据量小,并发量小的初创阶段。当数据量和并发量上去的时候,会出现主页读取慢的情况优点:feed存一份,存储小,逻辑简单缺点:用户集中访问数据,性能差(指拉取主页原创 2020-08-20 15:42:24 · 485 阅读 · 0 评论