首页
学习
活动
专区
工具
TVP
发布

架构师之路

专栏作者
459
文章
486731
阅读量
207
订阅数
好友新书发布,祝贺(送福利)
冰河的新书《深入理解高并发编程》发布了,祝贺。 看了内容,极其系统,图文并茂,非常硬核,很赞。 受邀写推荐序,很荣幸。 新书上架,第一时间推荐给大家,也送一批福利,希望大家有收获。 高并发,是海量用户在线系统架构所必须具备的特性。学习高并发的内核原理,学习高并发系统的工程架构最佳实践,从微观内核,到并发应用,再到业务架构,这本《深入理解高并发编程》都是不错的选择。 微观上,内核调度,同步异步,各类锁的实现细节,书中都有详尽的叙述;并发应用层面,CAS问题,ABA问题,连接池实现,书中都有细致的
架构师之路
2022-07-01
4970
为什么微服务并不是越早越好?
微服务架构,是分层架构演进过程中很重要的一环,那微服务是不是越早越好呢?今天和大家一起聊聊这一个问题。
架构师之路
2021-07-15
3960
数据库主从不一致,怎么解?
任何脱离业务的架构设计都是耍流氓,绝大部分业务,例如:百度搜索,淘宝订单,QQ消息,58帖子都允许短时间不一致。
架构师之路
2018-07-27
1.2K0
系统通知,居然有人使用拉取?
广义系统通知,有1对1的通知,以及一对多的通知,有相对实时的业务通知,以及能够容忍一定延时的系统通知。结合具体的场景来看下,这样的一些系统通知,究竟是推还是拉?
架构师之路
2018-07-27
8060
服务读写分离架构,绝不推荐
缘起 在《服务读写分离(读服务,写服务),是否可行?》中,对背景做了交代,互联网架构设计上,数据库可以读写分离,服务能否读写分离呢? 下面是两种常见的“服务读写分离”架构: 一、单纯服务读写分离 如上
架构师之路
2018-03-02
2.4K0
APP分层架构设计随想
互联网分层架构的本质,是数据的移动。 互联网分层架构演进的核心原则:让上游更高效的获取与处理数据(复用),让下游能屏蔽数据的获取细节(封装)。 不管数据怎么移动,最终都会汇聚到客户端。服务端的分层架构
架构师之路
2018-03-02
1.6K0
互联网分层架构之-DAO与服务化
互联网分层架构的本质,是数据的移动。 互联网分层架构演进的核心原则: 让上游更高效的获取与处理数据,复用 让下游能屏蔽数据的获取细节,封装 这些在上一篇《互联网分层架构的本质》中有详尽的描述,在实际系
架构师之路
2018-03-02
9860
计数系统架构实践一次搞定 | 架构师之路
提醒,本文较长,可提前收藏/转发。 一、需求缘起 很多业务都有“计数”需求,以微博为例: 微博首页的个人中心部分,有三个重要的计数: 关注了多少人的计数 粉丝的计数 发布博文的计数 微博首页的博文消
架构师之路
2018-03-02
2.5K2
单KEY业务,数据库水平切分架构实践 | 架构师之路
提醒,本文较长,可提前收藏/转发。 本文将以“用户中心”为例,介绍“单KEY”类业务,随着数据量的逐步增大,数据库性能显著降低,数据库水平切分相关的架构实践: 如何来实施水平切分 水平切分后常见的问题 典型问题的优化思路及实践 一、用户中心 用户中心是一个非常常见的业务,主要提供用户注册、登录、信息查询与修改的服务,其核心元数据为: User(uid, login_name, passwd, sex, age, nickname, …) 其中: uid为用户ID,主键 login_name, passwd,
架构师之路
2018-03-01
1K0
跨公网调用的大坑与架构优化方案
第三方接口挂掉,我们的服务会受影响么? 一、缘起与大坑 很多时候,业务需要跨公网调用一个第三方服务提供的接口,为了避免每个调用方都依赖于第三方服务,往往会抽象一个服务: 解除调用方与第三方接口的耦合
架构师之路
2018-03-01
1.4K0
DNS在架构设计中的巧用
一、缘起 一个http请求从客户端到服务端,整个执行流程是怎么样的呢? 一个典型流程如上: (1)客户端通过域名daojia.com请求dns-server (2)dns-server返回域名对应的
架构师之路
2018-03-01
1.9K0
互联网智能广告系统简易流程与架构 | 架构师之路
很多朋友估计没有做过这一块,争取最简洁的语言描述清楚。 一、业务简述 从业务上看 整个智能广告系统,主要分为: 1)业务端:广告主的广告后台 2)展现端:用户实际访问的页面 业务端,广告主主要有
架构师之路
2018-03-01
1.5K0
“配置”也有架构演进?看完深有痛感
一、缘起 随着互联网业务的越来越复杂,用户量与流量越来越大,“服务化分层”是架构演进的必由之路。 如上图:站点应用会调用服务,上游服务调用底层服务,依赖关系会变得非常复杂。 对于同一个服务,它有多个上
架构师之路
2018-03-01
8630
数据库秒级平滑扩容架构方案
一、缘起 (1)并发量大,流量大的互联网架构,一般来说,数据库上层都有一个服务层,服务层记录了“业务库名”与“数据库实例”的映射关系,通过数据库连接池向数据库路由sql语句以执行: 如上图:服务层配置
架构师之路
2018-03-01
2.6K0
深入浅出搜索架构引擎、方案与细节(上)
一、缘起 《100亿数据1万属性数据架构设计》文章发布后,不少朋友对58同城自研搜索引擎E-search比较感兴趣,故专门撰文体系化的聊聊搜索引擎,从宏观到细节,希望把逻辑关系讲清楚,内容比较多,分上下两期。 主要内容如下,本篇(上)会重点介绍前三章: (1)全网搜索引擎架构与流程 (2)站内搜索引擎架构与流程 (3)搜索原理、流程与核心数据结构 (4)流量数据量由小到大,搜索方案与架构变迁 (5)数据量、并发量、策略扩展性及架构方案 (6)实时搜索引擎核心技术 可能99%的同学不实施搜索引擎,但本文一定对
架构师之路
2018-03-01
4.4K0
究竟啥才是互联网架构“高并发”
一、什么是高并发 高并发(High Concurrency)是互联网分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计保证系统能够同时并行处理很多请求。 高并发相关常用的一些指标有响应时间(Response Time),吞吐量(Throughput),每秒查询率QPS(Query Per Second),并发用户数等。 响应时间:系统对请求做出响应的时间。例如系统处理一个HTTP请求需要200ms,这个200ms就是系统的响应时间。 吞吐量:单位时间内处理的请求数量。 QPS:每秒响应请求数。在互
架构师之路
2018-03-01
1.4K0
究竟啥才是互联网架构“高可用”
一、什么是高可用 高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一,它通常是指,通过设计减少系统不能提供服务的时间。 假设系统一直能够提供服务,我们说系统的可用性是100%。 如果系统每运行100个时间单位,会有1个时间单位无法提供服务,我们说系统的可用性是99%。 很多公司的高可用目标是4个9,也就是99.99%,这就意味着,系统的年停机时间为8.76个小时。 百度的搜索首页,是业内公认高可用保障非常出色的系统,甚至人们会通过www.baidu.com 能不能访问
架构师之路
2018-03-01
1.1K0
互联网架构,如何进行容量设计?
一,需求缘起 互联网公司,这样的场景是否似曾相识: 场景一:pm要做一个很大的运营活动,技术老大杀过来,问了两个问题: (1)机器能抗住么? (2)如果扛不住,需要加多少台机器? 场景二:系统设计阶段,技术老大杀过来,又问了两个问题: (1)数据库需要分库么? (2)如果需要分库,需要分几个库? 技术上来说,这些都是系统容量预估的问题,容量设计是架构师必备的技能之一。常见的容量评估包括数据量、并发量、带宽、CPU/MEM/DISK等,今天分享的内容,就以【并发量】为例,看看如何回答好这两个问题。 二,容量评
架构师之路
2018-03-01
1.9K0
58同城推荐系统架构设计与实现
主题 58同城推荐系统架构设计与实现 一、推荐系统架构介绍 推荐系统是一个微庞大的工程、算法与业务综合的系统,其主要分为三大子系统: 1)线下推荐子系统; 2)线上推荐子系统; 3)效果评估子系统;
架构师之路
2018-03-01
1.7K0
单点系统架构的可用性与性能优化
一、需求缘起 明明架构要求高可用,为何系统中还会存在单点? 回答:单点master的设计,会大大简化系统设计,何况有时候避免不了单点 在哪些场景中会存在单点?先来看一下一个典型互联网高可用架构。 典
架构师之路
2018-03-01
1.7K0
点击加载更多
社区活动
腾讯技术创作狂欢月
“码”上创作 21 天,分 10000 元奖品池!
Python精品学习库
代码在线跑,知识轻松学
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
技术创作特训营·精选知识专栏
往期视频·千货材料·成员作品 最新动态
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档