![](https://img-blog.csdnimg.cn/20201014180756919.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
架构与设计
文章平均质量分 83
kobejayandy
十多年互联网产品研发经验,历经华为、腾讯、字节跳动等公司,主要从事后端技术研发及技术管理工作(andyjaykobe)
展开
-
系统架构战略体系
系统架构战略体系分布式系统理念FLPCAPBASE分布式共识算法PaxosRaftGossip架构设计方法论架构设计方法论分而治之人类解决复杂问题的根本方法:分而治之,把复杂问题拆解成若干足够小的问题关注点分离好的架构必须使每个关注点相互分离,也就是说系统中的一个部分发生了变化,不会影响其他部分。即使需要改变,也能够清晰地识别出那些部分需要改变。如果需要扩展架构,影响将会最小化,已经可以工作的每个部分都将继续工作。架构设计思维架构设原创 2022-04-24 00:32:00 · 495 阅读 · 0 评论 -
关于高可用的系统
在《这多年来我一直在钻研的技术》这篇文章中,我讲述了一下,我这么多年来一直在关注的技术领域,其中我多次提到了工业级的软件,我还以为有很多人会问我怎么定义工业级?以及一个高可用性的软件系统应该要怎么干出来?这样我也可以顺理成章的写下这篇文章,但是没有人问,那么,我只好厚颜无耻的自己写下这篇文章了。哈哈。另外,我在一些讨论高可用系统的地方看到大家只讨论各个公司的技术方案,其实,高可用的系统并不简单的是技术方案,一个高可用的系统其实还包括很多别的东西,所以,我觉得大家对高可用的系统了解的还不全面,为了让大家的转载 2020-10-31 23:37:33 · 720 阅读 · 2 评论 -
Google服务器架构图解简析
Google,无疑是互联网时代最闪亮的明星。截止到今天为止,Google美国主站在Alexa排名已经连续3年第一,Alexa Top100中,各国的Google分站竟然霸占了超过20多个名额,不得不令人感叹Google的强大。不论何时,不论何地,也不论你搜索多么冷门的词汇,只要你的电脑连接互联网,只要你轻轻点击“google搜索”,那么这一切相关内容google都会在1秒钟之内全部搞定,这甚至转载 2014-05-03 21:39:08 · 5783 阅读 · 0 评论 -
中大型移动互联网公司技术架构选择
总体思考总结这些年经验,进行构架演进的方向选择时,大致要做到下面的目标:可快速开发部署 (五分钟写出来一个经过测试的hello world并可访问/调用,并可在公网访问)天然可扩展(业务层无状态,尽可能全部放到最后)自动化(内存不足了,除了报警,应该自动加点机器进去; 新的项目,基础代码应该都不用写,自动生成即可)框架化(公共层面的东西尽可能框架化,一层类似日志、c转载 2014-04-30 00:19:19 · 1564 阅读 · 0 评论 -
Web请求异步化
这两天在继续了解web应用中的异步处理问题。然后看到了淘宝文初的博客http://blog.csdn.net/cenwenchu79 ,他在几篇文章中多次提及jetty的continuation和servlet3的异步处理特性。看了之后收获不少。异步处理的层次异步处理在Web应用中可以分三个层次:Socket数据传输的异步化(NIO)HTTP请求的异步化(Jetty Continu转载 2013-09-30 23:53:48 · 1880 阅读 · 0 评论 -
同步调用与异步调用
同步所谓同步,就是在发出一个功能调用时,在没有得到结果之前,该调用就不返回。也就是必须一件一件事做,等前一件做完了才能做下一件事。按照这个定义,其实绝大多数函数都是同步调用(例如sin,isdigit等)。但是一般而言,我们在说同步、异步的时候,特指那些需要其他部件协作或者需要一定时间完成的任务。最常见的例子就是SendMessage。该函数发送一个消息给某个窗口,在对方处理完消息之前,这转载 2013-12-24 23:54:21 · 5245 阅读 · 1 评论 -
关于异步的思考
云平台的工作流框架AWS Flow Framework给我带来的另一个有所感触的话题是“异步”:这个框架把异步的行为划分为Workflow端执行的部分和Activity端执行的部分,Workflow控制工作流程,Activity执行具体的工作流task,二者都以poll的模式不断从中心SWF去获取任务。对于开发者来说,用类似这样简单的代码,就完成了整个工作流任务的部署,框架为开发人员隐藏了转载 2013-12-24 00:13:23 · 982 阅读 · 0 评论 -
从饭店谈起,看支付宝Zqueue系统如何应对双11
2011年11月10日,世纪光棍节前夜,支付宝大楼的一间大型会议室里,数十号人严阵以待。0点刚过,投影在幕布上的交易、支付曲线,几乎成90度直线上升。仅仅几秒钟之后,支付宝大促专用旺旺群开始闪烁:“【支付宝大促决策-#1】对*行执行渠道限流措施”,“【支付宝大促决策-#2】对*行网银执行渠道限流措施”,“【金融渠道决策参数调整-#1】:**银行收银台限流:3QP3M”,“【金融转载 2013-12-22 23:23:10 · 2317 阅读 · 0 评论 -
大型网站架构不得不考虑的10个问题
这里的大型网站架构只包括高互动性高交互性的数据型大型网站,基于大家众所周知的原因,我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构 了,我们以高负载高数据交换高数据流动性的网站为例,比如海内,开心网等类似的web2.0系列架构。我们这里不讨论是PHP还是JSP或者.NET环 境,我们从架构的方面去看问题,实现语言方面并不是问题,语言的优势在于实现而不是好坏,不论你选择任何语言,架构都是必须转载 2013-12-22 23:01:06 · 944 阅读 · 0 评论 -
异步调用和回调函数
异步调用在应用程序框架中具有广泛的应用,并且特指多线程情况下。它同Windows的消息循环机制,消息响应,消息队列,事件驱动机制以及设计模式中的观察者模式等都是紧密相关的。 回调函数用于层间协作,上层将本层函数安装在下层,这个函数就是回调,而下层在一定条件下触发回调,例如作为一个驱动,是一个底层,他在收到一个数据时,除了完成本层的处理工作外,还将进行回调,将这个数据交给上层应用层来转载 2013-12-29 16:26:36 · 12589 阅读 · 5 评论 -
大型网站的高可用分析
本文主要分析网站的高可用性,从应用需求、用户角度展开分析。1.1 高可用性“高可用性”(High Availability) 通常用来描述一个系统,经过特殊设计,减少停止服务的时间,从而使其服务保持高度的可使用性。计算机系统的可靠性用平均无故障时间(MTTF)来度量,即计算机系统平均能够正常运行多长时间,才会发生一次故障。系统的可靠性能越高,平均无故障时间越长。可维护性用平转载 2013-12-10 23:38:32 · 780 阅读 · 0 评论 -
大型网站后台架构的web server与缓存
网站的web server与缓存1.1 Web serverWebserver 用来解析HTTP协议。当web 服务器接收到一个HTTP请求时,会返回一个HTTP响应,例如送回一个HTML页面。为了处理一个请求,web服务器可以响应一个静态页面或者图片。进行页面跳转,或者把动态响应的产生委托给一些其它的程序完成,比如CGI,JSP,servlets,ASP,PHP脚本。转载 2013-12-10 23:47:38 · 1231 阅读 · 0 评论 -
大型网站的监控、报警与故障转移
本章主要从大型网站的后台监控机制、报警机制和故障转移、服务切换等内容来论述。然后给出一个监控、报警和故障转移的解决方案。1.1 监控预警现代大型互联网公司主要有电子商务公司、社交网站公司和搜索引擎公司。在电子商务网站公司中,taobao.com的点击量在国内是最高的。日点击量20亿以上。而这个点击量还不是均匀分不到24个小时,而是分布在几个时间段。因为人们的购物时间是集中在几个不同转载 2013-12-10 23:46:24 · 1717 阅读 · 0 评论 -
后台服务器设计模型总结
根据服务器后台操作是否会被阻塞可以分为同步和异步两大类同步模型l 单进程同步模型: 服务器只有在处理完成前一个客户请求才能处理下一个请求,最简单的服务器设计模型,没有之一,性能基本取决于后台操作的耗时。l 多进程同步(fork)模型:每来一个请求fork一个进程处理,优点是进程之间,地址空间互相独立,因此处理起来也非常简单,缺点就是fork系统资源消耗较大,进程之间共享转载 2014-04-19 21:35:04 · 2122 阅读 · 0 评论 -
Protocol Buffer技术详解(语言规范)
该系列Blog的内容主体主要源自于Protocol Buffer的官方文档,而代码示例则抽取于当前正在开发的一个公司内部项目的Demo。这样做的目的主要在于不仅可以保持Google文档的良好风格和系统性,同时再结合一些比较实用和通用的用例,这样就更加便于公司内部的培训,以及和广大网友的技术交流。需要说明的是,Blog的内容并非line by line的翻译,其中包含一些经验性总结,与此同时,对于一转载 2014-04-24 13:09:56 · 827 阅读 · 0 评论 -
技术选型:Sentinel vs Hystrix
Sentinel 是阿里中间件团队研发的面向分布式服务架构的轻量级高可用流量控制组件,于今年7月正式开源。Sentinel 主要以流量为切入点,从流量控制、熔断降级、系统负载保护等多个维度来帮助用户提升服务的稳定性。大家可能会问:Sentinel 和之前经常用到的熔断降级库 Netflix Hystrix 有什么异同呢?本文将从资源模型和执行模型、隔离设计、熔断降级、实时指标统计设计等角度将...转载 2019-01-27 22:08:45 · 318 阅读 · 0 评论 -
服务器端开发总结
1. 服务异步化网络IO处理异步化(NIO, Jetty Continuation,Servlet 3)服务的异步化(Future, Callable, Runnable, Callback) 2. 线程与协程多线程并发或者协程支持并发,相比而言,协程在处理IO密集型更具优势 3. 缓存无处不在前端、CGI、后台能用缓存的地方尽量使用缓存,极大的提高系统性能,包括分布式缓存,本地缓存等等原创 2014-12-05 03:42:16 · 2440 阅读 · 0 评论 -
服务器端开发技术
1. 多进程或多线程模型多进程服务器:Apache,Nginx,lighttpd等服务器均为多进程模型,分为Master进程和Woker进程多进程的优点:更强的容错性 - 一个进程挂掉不会导致整个系统崩溃,更好的多核可伸缩性 - 进程的使用将许多内核资源(如地址空间,页表,打开的文件)隔离,在多核系统上的可伸缩性强于多线程程序。多线程服务器:Tomcat,Netty等服务器均为多线程模原创 2014-12-05 03:20:46 · 7098 阅读 · 0 评论 -
面向海量服务的设计原则和策略总结
面向海量服务的设计原则和策略总结 互联网服务的特点就是面向海量级的用户,面向海量级的用户如何提供稳定的服务呢?这里,对这几年的一些经验积累和平时接触的一些理念做一个总结。 一、原则 1.Web服务的CAP原理 CAP指的是三个要素:一致性(Consistency)、可用性(Availability)、分区容忍性(Partition t转载 2014-08-29 23:43:55 · 1538 阅读 · 0 评论 -
Amazon Dynamo论文解读 - Merkle Tree的使用
Merkle Tree是Dynamo论文中用到的一个算法,读这篇论文前,我并不知道这个算法,所以找了相关资料了解了解,以便我对论文有更进一步的了解。 什么是Merkle Tree Merkle Tree,是一种树(数据结构中所说的树),网上大都称为Merkle Hash Tree,这是因为 它所构造的Merkle Tree的所有节点都是Hash值。Merkle Tree转载 2014-07-01 20:52:53 · 831 阅读 · 0 评论 -
解读NoSQL技术代表之作Dynamo
NoSQL在过去的一年里,逐渐已经成为了家喻户晓的东西,我(54chen)自从去年开始人人网的NoSQL系统Nuclear的研发以来,一直看NoSQL越来越热,越来越引来大家的围观。受InfoQ中文站编辑之托,特作此文,一来作为过去一年的总结,二来希望对NoSQL系统在国内的发展和推广尽绵薄之力。NoSQL背后的两种模式NoSQL其实并不是什么妖魔鬼怪,相反,NoSQL的真谛其实应转载 2014-07-01 20:59:07 · 1549 阅读 · 0 评论 -
微信架构的启示
腾讯大讲堂中最近分享了周颢演讲的微信技术总监解读微信架构的秘密,看完视频的一些心得。技术微创新微信的技术设计上有很多微创新,看起来都很小,但是对于系统的稳定性、用户体验及开发敏捷都具有重要作用。前轻后重由于客户端升级不便,从技术设计上尽量利用后端的设计来减少依赖客户端升级的方法。如某个版本新增了群聊功能,按常规思路,需要所有客户端升级才能全部打通。微信采用服务器兼容的方法,转载 2014-07-01 20:09:35 · 1698 阅读 · 0 评论 -
互联网架构设计的几个原则
一,可(异地)部署和就近路由接入,破除单点故障; (可分布,可调度的原则) 二,数据上报和监控平台; (用户行为数据,系统性能监控数据,系统异常和业务相关数据等的上报) 三,数据分级存储原则:单内存cache存储,内存cache+异步更新,内存cache+同步更新; (从三个纬度分析用户行为模型,决定相关数据的存转载 2014-06-30 20:45:44 · 4524 阅读 · 0 评论 -
互联网系统的架构设计必须要考虑的关键点
前两天听了海量用户服务系列课后,收获颇多,快速整理下思路,几个基本点:一,互联网产品是一个运营的产品,产品的成功很大程度上是运营出来的,而不是开发出来的,从产品的生命周期看,开发环节只是占了其中的一小部分,而产品的生命周期大部分是处于运营状态,因此,在架构设计阶段就必须把产品的可运营性纳入到设计的重要思考点,而绝对不是简单的实现一个功能点就大功告成了。 二,什么是可运营的产转载 2014-06-30 20:43:34 · 3251 阅读 · 0 评论 -
服务管理框架的尝试
大型软件系统开发需要模块化,在分布式系统中,模块化通常是将功能分成不同的远程服务(RPC)来实现。比如可以用Java RMI、Web Service、Facebook开源的Thrift等一些技术。同样,在一个大型系统中,服务化之后服务的可维护、可管理、可监控以及高可用、负载均衡等因素同服务本身同样重要。服务管理目前并无直接解决方案,如果开发一个自己的服务管理框架,需要具备以转载 2014-07-17 23:42:51 · 1078 阅读 · 0 评论 -
互联网系统架构的演进
多终端接入、开放平台给互联网带来了前所未有的用户量级和访问规模,SNS网站产生了海量的UGC(用户产生内容),而且这些内容依托关 系链扩散速度之快、传播范围之广是传统网站难以想象的,海量数据的计算存储也一直是近年互联网领域的热点。本文将从发展演进的层面探讨互联网的系统架构。天下武功唯快不破网站初期的架构一般采用“短平快”的架构思路,架构以简单清晰、容易开发为第一衡量指标。互转载 2014-04-25 00:28:25 · 982 阅读 · 0 评论 -
大型网站的负载均衡器、db proxy和db
大型网站的负载均衡器、db proxy和db本文主要分析网站后台架构中的负载均衡器,企业常用的硬件负载均衡器软件负载均衡器、数据库代理服务器和数据库。1.1 负载均衡在大型网站部署中,负载均衡至少有三层部署。第一层为web server或者缓存代理之上的负载均衡,第二层为数据库之上的负载均衡,第三层为存储设备之上的负载均衡。在第一层部署中,最常使用的是硬件负载均衡器转载 2013-12-10 23:47:01 · 1040 阅读 · 0 评论 -
瞬时响应:网站的高性能架构
什么叫高性能的网站? 两个网站性能架构设计方案:A方案和B方案,A方案在小于100个并发用户访问时,每个请求的响应时间是1秒,当并发请求达到200的时候,请求的响应时间将骤增到10秒。B方案不管是100个并发用户访问还是200个并发用户访问,每个请求的响应时间都差不多是1.5秒。哪个方案的性能好?如果老板说“我们要改善网站的性能”,他指的是什么? 同类型的两个网站,X网站服务器平均每个转载 2013-12-10 23:36:09 · 1046 阅读 · 0 评论 -
海量数据问题和解决方案搜集汇总
传统关系型数据的问题 1. 扩展困难:由于存在类似Join这样多表查询机制,使得数据库在扩展方面很艰难; 2. 读写慢:这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂,使得其非常容易发生死锁等的并发问题,所以导致其读写速度下滑非常严重; 3. 成本高:企业级数据库的License价格很惊人,并且随着系统的规模,而不断上升; 4. 有限的支撑容量:现有关转载 2013-11-24 23:22:37 · 1321 阅读 · 0 评论 -
软件架构师应该知道的97件事
1. 客户需求重于个人简历不要为了学习新的知识或丰富自己的简历而选择新技术解决问题,要尽量选择切合实际的技术解决客户的难题。脚踏实地的为客户着想,选择正确的方案可以降低项目的压力,团队工作起来更开心,客户也会更满意,从而你也会有更充裕的时间学习新的知识。 2. 简化根本复杂性,消除偶发复杂性根本复杂性是问题本身就很复杂,所以它是无法避免的。偶发复杂性是在解决根本复杂性的过程中衍转载 2013-08-01 20:27:50 · 2596 阅读 · 0 评论 -
高并发大型网站架构设计
一个大型的网站网站应该由如下6个子系统组成 负载均衡系统反向代理系统Web服务器系统分布式存储系统底层服务系统数据库集群系统 为什么要做高并发系统设计?事实上,针对于任何单一的网络服务器程序,其可承受的同时连接数目是有理论峰值的,通过C++中对TSocket的定义类型:word,我们可以判定这个连接理论峰值是65535,也就是说,你的单个服务器程序,最多可转载 2013-07-31 22:47:05 · 1123 阅读 · 0 评论 -
大型互联网网站架构心得之一:分
我们知道,对于一个大型网站来说,可伸缩性是非常重要的,怎么样在纵向和横向有良好的可伸缩性,就需要在做架构设计的时候考虑到一个分的原则,我想在多个方面说一下怎么分:首先是横向的分:1. 大的网站化解为多个小网站:当我们一个网站有多个功能的时候,可以考虑把这个网站拆分成几个小模块,每一个模块可以是一个网站,这样的话我们到时候就可以很灵活地去把这些网站部署到不同的服务器上。2. 静态动态分离转载 2013-07-23 23:03:10 · 919 阅读 · 0 评论 -
打造高可用,高可扩展的互联网平台
很多互联网公司早期初创,为了快速开发出应用产品,基本都是采用LAMP技术组合来搭建网站。由于开发人员也不是很多,所以采用在一个工程下开发,或者一个工程下的多模块开发。随着公司的业务和流量快速膨胀,人员规模也从数十人扩张到数百人,导致网站的开发,部署,运维带来很大的挑战: 1)众多开发人员围着一个工程开发,打包,测试,部署纠结在一起,互相等待,严重的影响了生产效率;转载 2013-07-23 22:44:14 · 993 阅读 · 0 评论 -
大型互联网网站架构心得之二:并、换
上次说的“分”是一个比较大的原则也是一个比较高层的原则,这次我想说一下其它两个原则:并与换。 并 为什么要分?是因为我们希望通过分来提高系统的承载能力,那并又是并什么呢?我想了一下有几个方面可以并: 1. 合并用户请求,最基本的就是合并CSS/图片/脚本,还可以合并页面。不过合并就可能产生流量的浪费,需要有一个平衡点。2. 合并接口的粒度,如果做转载 2013-07-23 23:04:26 · 824 阅读 · 0 评论 -
服务器端编程的十大性能问题
今年5月底,瑞士计算机世界杂志上刊登了Web性能诊断专家Bernd Greifeneder的一篇文章,文章列举了其在过去几年工作中所遇到的服务器端编程的十大性能问题。Andreas Grabner则在自己的博客上对这些性能问题给出了进一步阅读的链接。希望这些问题与相关的延伸阅读能为广大的InfoQ读者带来一定的启示。问题一:过多的数据库调用我们发现经常出现的一个问题就是在每次请求/事务转载 2013-06-04 22:29:38 · 824 阅读 · 0 评论 -
各大型网站架构分析收集
1. PlentyOfFish 网站架构学习http://www.dbanotes.net/arch/plentyoffish_arch.html采取 Windows 技术路线的 Web 2.0 站点并不多,除了 MySpace ,另外就是这个 PlentyOfFish。这个站点提供 “Online Dating” 服务。一个令人津津乐道的、惊人的数据是这个只有一个人(创建人Marku转载 2013-05-18 22:55:21 · 1016 阅读 · 0 评论 -
大型网站架构演变
之前也有一些介绍大型网站架构演变的文章,例如LiveJournal的、ebay的,都是非常值得参考的,不过感觉他们讲的更多的是每次演变的结果,而没有很详细的讲为什么需要做这样的演变,再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术,于是有了写这篇文章的想法,在这篇文章中将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系,希望能给想从事互联网行转载 2013-05-18 20:33:56 · 888 阅读 · 0 评论 -
Google App Engine技术架构资料大盘点
今天看到几篇有关Google App Engine的技术架构文章,一起分享给大家,没看到过的同学赶紧惊喜一下吧,看到过了的同学也假装惊喜一下嘛,呵呵。全部文章有点长,请耐心看下去,相信程序员都是有耐心的,除了我.......一、Google的核心技术在切入Google App Engine之前,首先会对Google的核心技术和其整体架构进行分析,以帮助大家之后更好地理解Google A转载 2013-03-06 23:44:44 · 800 阅读 · 0 评论 -
大型网站架构不得不考虑的10个问题
本文以高负载高数据交换高数据流动性的网站为例,从架构的方面讲解了对如开心我、海内网等高互动性高交互性的数据型大型网站架构设计时需要注意的10个问题。 这里的大型网站架构只包括高互动性高交互性的数据型大型网站,基于大家众所周知的原因,我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了,我们以高负载高数据交换高数据流动性的网站为例,比如海内,开心网等类似的web2.0系列架构。我们这里转载 2013-03-06 00:01:15 · 679 阅读 · 0 评论 -
软件架构设计箴言理解
今天和师弟聊天聊到他们项目开发,有些同事总是提前考虑性能优化,需求变更又是一大堆的重写,让我想起了Donald Knuth 提到的:对软件的过早地优化是万恶的根源。这里就简单的说几条重要的软件名人哲学。1:软件中唯一不变的就是变化。在软件开发过程中需求是不停的变化,随着客户对系统的认识,和现有开发功能和软件的认识,也许以开始他提出的需求就是背离的。记得网上有一句笑话,师说需求变化的:转载 2013-03-05 23:40:39 · 817 阅读 · 0 评论