软件架构
shengxiaweizhi
这个作者很懒,什么都没留下…
展开
-
林仕鼎:系统架构领域的一些学习材料
系统架构是一个工程和研究相结合的领域,既注重实践又依赖理论指导,入门容易但精通很难,有时候还要讲点悟性,很具有“伪科学”的特征。要在此领域进阶,除了要不断设计并搭建实际系统,也要注意方法论和设计理念的学习和提炼。经常有同学询问如何学习,特贴一篇学习材料,供大家参考。09年时写的,在系统领域浩如烟海的文献中提取了一些我认为值得研究和学习的项目,没包括近几年出现的一些工作,也不够全面。不过,其实也转载 2015-05-29 22:17:36 · 581 阅读 · 0 评论 -
The Log
前言这是一篇学习笔记。学习的材料来自Jay Kreps的一篇讲Log的博文。原文很长,但是我坚持看完了,收获颇多,也深深为Jay哥的技术能力、架构能力和对于分布式系统的理解之深刻所折服。同时也因为某些理解和Jay哥观点吻合而略沾沾自喜。Jay Kreps是前Linkedin的Principal Staff Engineer,现任Confluent公司的联合创始人和CEO,Kafka转载 2015-07-20 00:35:26 · 513 阅读 · 0 评论 -
网站的消息通知系统设计漫谈
现在的很多网站都有消息通知系统,比如新浪微博页面右上角的小黄签,比如Facebook页面左上角的Notifications。但是消息通知系统的说法是个笼统的概念,我理解的其本质功能是网站把某些对用户有价值的信息及时告知用户。比如常见的SNS关系中谁关注了你,谁评价了你发布的内容,谁邀请你加入某个小组等。这类消息可以大体上分为两类,一种是告知性质的,就是用户知道有这么回事就行了,最多是具体看一下转载 2015-06-07 18:55:40 · 2353 阅读 · 0 评论 -
分布式发布订阅消息系统 Kafka 架构设计
我们为什么要搭建该系统 Kafka是一个消息系统,原本开发自LinkedIn,用作LinkedIn的活动流(activity stream)和运营数据处理管道(pipeline)的基础。现在它已为多家不同类型的公司 作为多种类型的数据管道(data pipeline)和消息系统使用。活动流数据是所有站点在对其网站使用情况做报表时要用到的数据中最常规的部分。活动数据包括页面访问量(pag转载 2015-06-07 18:50:29 · 1934 阅读 · 0 评论 -
分布式系统设计原理与方案
一直在思考分布式系统设计的问题,业务对象原封不动的情况下部署在客户端和服务器端,可以根据配置文件选择是连接服务器还是连接本地的数据库,这个问题让我绞尽脑汁,我总是设想的客户端与服务器端通信的方式是最低端的Socket。花了两个晚上研究CSLA.NET框架关于数据门户这块代码,才发现问题的关键所在:客户端与服务器端通信不能采用最低端的Socket,而要用高端的WebService、.NET Remo转载 2015-06-07 19:12:16 · 1958 阅读 · 0 评论 -
KAFKA分布式消息系统
Kafka[1]是linkedin用于日志处理的分布式消息队列,linkedin的日志数据容量大,但对可靠性要求不高,其日志数据主要包括用户行为(登录、浏览、点击、分享、喜欢)以及系统运行日志(CPU、内存、磁盘、网络、系统及进程状态)。 当前很多的消息队列服务提供可靠交付保证,并默认是即时消费(不适合离线)。高可靠交付对linkedin的日志不是必须的,故可通过降低可靠性来提高性能,同时转载 2015-06-07 19:05:50 · 547 阅读 · 0 评论 -
中大型移动互联网公司技术架构选择
总体思考总结这些年经验,进行构架演进的方向选择时,大致要做到下面的目标:可快速开发部署 (五分钟写出来一个经过测试的hello world并可访问/调用,并可在公网访问)天然可扩展(业务层无状态,尽可能全部放到最后)自动化(内存不足了,除了报警,应该自动加点机器进去; 新的项目,基础代码应该都不用写,自动生成即可)框架化(公共层面的东西尽可能框架化,一层类似转载 2015-05-30 22:51:13 · 495 阅读 · 0 评论 -
铁路订票系统的简单设计
其实铁路订票系统面临的技术难点无非就是春运期间可能发生的海量并发业务请求。这个加上一个排队系统就可以轻易解决的。 本来我在 weibo 上闲扯两句,这么简单的方案,本以为大家一看就明白的。没想到还是许多人有疑问。好吧,写篇 blog 来解释一下。 简单说,我们设置几个网关服务器,用动态 DNS 的方式,把并发的订票请求分摊看。类比现实的话,就是把人分流到不同的购票大厅去。每个购转载 2015-05-30 22:39:10 · 837 阅读 · 0 评论 -
实时处理日均50亿会话,解析Twitter Answers的架构
去年我们发布了Answers,至今移动社区产生了惊人的使用量,让我们感到兴奋不已。现在Answers每天处理50亿次会话,并且这个数量在持续增加。上亿设备每秒向Answers端点发送数以百万计的请求。在你已经阅读到此处的这段时间里,Answers后台收到并处理了一千万次分析事件。其中的挑战是如何利用这些信息向移动开发者提供可靠的、实时的、有实际价值的洞见(视角)去了解他们的移动应用。在高层转载 2015-05-29 22:22:08 · 554 阅读 · 0 评论 -
构建亿级前端读服务
从入职京东到现在,做读服务已经一年多的时间了,经历了各种亿级到百亿级的读服务;这段时间也进行了一些新的读服务架构尝试,从架构到代码的编写,各个环节都进行了反复尝试,压测并进行调优,希望得到一个自己满意的读服务架构。 一些设计原则无状态数据闭环缓存银弹并发化降级开关限流切流量其他无状态如果设计的应用是无状态的,那么应用就可以水平扩展,当然实际生转载 2015-08-03 22:25:01 · 763 阅读 · 0 评论