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

架构师之路

专栏作者
459
文章
489919
阅读量
207
订阅数
必须知道的RPC内核细节(值得收藏)!!!
微服务分层架构,之前聊得很多了,微服务离不开RPC框架,RPC框架的原理、实践及细节,今天和大家聊一聊。 文章较长,1万字左右,建议提前收藏。 服务化有什么好处? 服务化的一个好处就是,不限定服务的提供方使用什么技术选型,能够实现大公司跨团队的技术解耦,如下图所示: (1)服务A:欧洲团队维护,技术背景是Java; (2)服务B:美洲团队维护,用C++实现; (3)服务C:中国团队维护,技术栈是go; 服务的上游调用方,按照接口、协议即可完成对远端服务的调用。 但实际上,大部分互联网公司,研发团队规模
架构师之路
2022-06-24
6230
1万行代码,单机50万QPS,今年最值得学习的开源RPC框架!
如果没有统一的RPC框架,各个团队的服务提供方就需要各自实现一套序列化、反序列化、网络框架、连接池、收发线程、超时处理、状态机等“业务之外”的重复技术劳动,造成整体的低效。
架构师之路
2021-11-30
8120
为什么说,MQ,是互联网架构的解耦神器?
耦合,是架构中,本来不相干的代码、模块、服务、系统因为某些原因联系在一起,各自独立性差,影响则相互影响,变动则相互变动的一种架构状态。
架构师之路
2021-09-07
4870
我C,一个库里Curry几百个表,这谁受得了?
随着业务越来越复杂,数据量越来越大,并发量越来越大,数据库的性能越来越低。好不容易找运维申请了两台机器,让DBA部署了几个实例,想把一些业务库拆分出来,却发现一个库里几百个表,拆不出来,扩不了容,尴尬!
架构师之路
2021-09-07
2790
服务之间通过缓存传递数据,我坚决反对!
如果只是单纯的将cache作为两个服务数据通讯的管道,service-A生产数据,service-B(当然,可能有service-C/service-D等)订阅数据,MQ比cache更加合适:
架构师之路
2021-07-15
6470
究竟为啥总在凌晨上线,如何进行无损发布
如上图,重启ip1上的tomcat时,tomcat上或许有1000个http请求正在处理,这些请求就会失败。
架构师之路
2020-12-14
5300
怎样的监控,才真正说明系统有问题?
监控不告警,系统就一定没有问题么?怎样的监控,才真正说明系统有问题?今天和大伙聊聊多维度立体化监控。
架构师之路
2020-12-14
6150
业务层,到底需不需要服务化?
除了基础数据的访问需要服务化,业务层是否需要服务化?如果需要,什么时机进行服务化?这是本文要讨论的两个问题。
架构师之路
2020-11-11
5001
每秒几万次MySQL交互,搜狗纯异步MySQL客户端开源了!
今年看源码,之前推荐过一个框架《单机40万QPS,搜狗WF框架,今年最值得学习的开源代码》,随着源码阅读的越来越深入,发现了WF框架一个非常独特的地方:高性能纯异步MySQL客户端,非常有意思,今天和大家介绍一下自己的学习心得。
架构师之路
2020-11-03
1.4K0
单机40万QPS,搜狗WF框架,今年最值得学习的开源代码
职业生涯的前五年,基本上都在做即时通讯业务,由于业务的特殊性,吞吐量极大,时延不这么敏感,团队内部单独开发了一套纯异步omni框架。
架构师之路
2020-09-28
1.1K0
构建基于ServiceMesh的中台架构
微服务架构中,随着数据量不断增大,吞吐量不断增加,业务越来越复杂,服务的个数会越来越多,分层会越来越细,除了数据服务层,还会衍生出业务服务层,前后端分离等各种层次结构。
架构师之路
2020-05-14
6940
究竟什么时候该使用MQ?
任何脱离业务的组件引入都是耍流氓。引入一个组件,最先该解答的问题是,此组件解决什么问题。
架构师之路
2020-03-23
5910
多维度立体化监控,才是真的监控
前文介绍了通用+可扩展的http监控平台与log监控平台的架构: 《通用+可扩展http监控平台/框架》 《通用+可扩展log监控平台/框架》 结果,评论里各种冷嘲热讽。 监控这个topic本来有很多细节可以聊,既然大伙公司都做得比较完善,后续就不纠细节了,聊聊方向上的思考,架构上的设计。今天和大伙聊聊多维度立体化监控。 一、什么是多维度立体化监控 不同公司或多或少有一些自动化监控手段,除了前文提到的: http接口监控 log关键字监控 还有很多维度的监控: 操作系统,进程,端口 http状态码 服务存活
架构师之路
2018-03-02
2.8K0
如何实施异构服务器的负载均衡及过载保护?
零、需求缘起 第一篇文章“一分钟了解负载均衡”和大家share了互联网架构中反向代理层、站点层、服务层、数据层的常用负载均衡方法。 第二篇文章“lvs为何不能完全代替DNS轮询”和大家share了互联网接入层负载均衡需要解决的问题及架构演进。 在这两篇文章中,都强调了“负载均衡是指,将请求/数据【均匀】分摊到多个操作单元上执行,负载均衡的关键在于【均匀】”。 然而,后端的service有可能部署在硬件条件不同的服务器上: 1)如果对标最低配的服务器“均匀”分摊负载,高配的服务器的利用率不足; 2)如果对标最
架构师之路
2018-03-02
1.9K0
“id串行化”到底是怎么实现的?
一、需求缘起 在上一篇文章《消息“时序”与“一致性”为何这么难?》中,介绍了一种为了保证“所有群友展示的群消息时序都是一致的”所使用的“id串行化”的方法:让同一个群gid的所有消息落在同一台服务器上
架构师之路
2018-03-02
1.1K0
服务读写分离(读服务,写服务),是否可行?
系统分层架构有一个迭代和演进的过程,早期,系统分层架构如下: 上游是需要数据的业务调用方 下游是存储数据的数据库 随着架构的演进,可能要抽取出服务层(详见《互联网架构为什么要做服务化?》): 上游通过
架构师之路
2018-03-02
1.3K0
MQ,互联网架构解耦神器
一个架构常识:当调用方需要关心执行结果,通常使用RPC调用。 ret = PassportService::userAuth(name, pass); switch(ret){ case(YES)
架构师之路
2018-03-02
1.4K0
互联网分层架构,为啥要前后端分离?
通用业务服务化之后,系统的典型后端结构如上: web-server通过RPC接口,从通用业务服务获取数据 biz-service通过RPC接口,从多个基础数据service获取数据 基础数据service通过DAO,从独立db/cache获取数据 db/cache存储数据 随着时间的推移,系统架构并不会一成不变,业务越来越复杂,改版越来越多,此时web-server层虽然使用了MVC架构,但以下诸多痛点是否似曾相识? 产品追求绚丽的效果,并对设备兼容性要求高,这些需求不断折磨着使用MVC的Java工程师
架构师之路
2018-03-02
8390
啊,业务层是否也需要服务化?
《互联网分层架构的本质》简述了两个观点: 互联网分层架构的本质,是数据的移动 互联网分层架构演进的核心原则:是让上游更高效的获取与处理数据,让下游能屏蔽数据的获取细节 《分层架构:什么时候抽象DAO层,什么时候抽象数据服务层》中的观点是: 当手写代码从DB中获取数据,成为通用痛点的时候,就应该抽象出DAO层,简化数据获取过程,提高数据获取效率,向上游屏蔽底层的复杂性 当业务越来越复杂,垂直拆分的系统越来越多,数据库实施了水平切分,数据层实施了缓存加速之后,底层数据获取复杂性成为通用痛点的时候,就应该抽象出数
架构师之路
2018-03-02
1.2K0
工作线程数究竟要设置为多少 | 架构师之路
一、需求缘起 Web-Server通常有个配置,最大工作线程数,后端服务一般也有个配置,工作线程池的线程数量,这个线程数的配置不同的业务架构师有不同的经验值,有些业务设置为CPU核数的2倍,有些业务设置为CPU核数的8倍,有些业务设置为CPU核数的32倍。 “工作线程数”的设置依据是什么,到底设置为多少能够最大化CPU性能,是本文要讨论的问题。 二、共性认知 在进行进一步深入讨论之前,先以提问的方式就一些共性认知达成一致。 问:工作线程数是不是设置的越大越好? 答:肯定不是的 服务器CPU核数有限,能够同
架构师之路
2018-03-02
1.7K0
点击加载更多
社区活动
RAG七天入门训练营
鹅厂大牛手把手带你上手实战,赢鹅厂证书、公仔好礼!
Python精品学习库
代码在线跑,知识轻松学
博客搬家 | 分享价值百万资源包
自行/邀约他人一键搬运博客,速成社区影响力并领取好礼
技术创作特训营·精选知识专栏
往期视频·千货材料·成员作品 最新动态
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档