架构与设计
猴哥_IT小菜鸟
三分天注定七分靠打拼 爱拼才会赢
展开
-
详细介绍软件架构设计的三个维度
架构设计是一个非常大的话题,不管写几篇文章,接触到的始终只是冰山一角,更多的是实践中去体会。这篇文章主要介绍面向对象OO、面向方面AOP和面向服务SOA这三个要素在架构设计中的位置与作用。 架构设计有三个维度,或者说是我们在考虑架构时需要思考三个方向。这三个维度分别为面向对象、面向方面、面向服务。这三个维度可以看作是正交的,但不同维度会互相印证,互相支撑,整个架构的示意图如图所示。面向对象转载 2017-02-14 17:40:15 · 509 阅读 · 0 评论 -
13种提高系统伸缩性的最佳实践
1, 尽可能地使用异步通信.2, 为提供不同服务的硬件引入故障隔离.3, 在多层系统中, 使用Cache.4, 从用户角度监控你的系统性能.5, 使用数据库复制, 降低单点读压力.6, 根据用户和业务的不同, 将应用或数据库分片.7, 减少使用关系型数据库的复杂特性. 尽可能把它当做是一个持久存储设备.8, 以循序渐进的方式升级系统, 先升级小部分servers, 然后逐步升级所有se转载 2017-02-14 17:32:35 · 400 阅读 · 0 评论 -
15种提高系统伸缩性和性能的最佳实践
1, 提高系统性能, 需要尽早做性能剖析, 而且要经常做.当项目进行到后期, 你再考虑剖析性能时, 复杂的系统结构会让你望而却步.2, 开发者和SA的合作是有必要的, SA可以反馈线上的运行状况给开发者, 防止一些紧急事故的发生, 恶化.3, 模拟生产环境的数据来做测试, 可以减少上线时, 出现未知问题的概率, 使问题更早的被暴露出来.4, 通过监控日志, 查看系统负载, 分析程序运行状况等手转载 2017-02-14 17:32:07 · 357 阅读 · 0 评论 -
常用模式的细节问题看设计稳定性
这部分内容是我前个礼拜作内部分享的一部分,是挑了大家在日常中经常使用的生产者消费者模式作了一个细节问题的分析来讲述关于系统设计中的一些问题,其实在我前面的救火经验分享里面也有部分的介绍,不过那些比较抽象一点,需要有实际的工作经历的同学才会体会的到,而这里就具体的针对某一个特定场景作了分析. 图 1 生产者消费者模式 生产者和消费者模式在我们日常生产的代码里面应该出现的很频繁,但是有转载 2017-02-14 17:31:38 · 157 阅读 · 0 评论 -
Apache软件体系结构
Apache不同的版本,软件体系结构差别还是比较大,一种是进程式处理connection request,另外一种是线程式处理connection request.进程式处理如下图所示:如果连接比较多,parent进程会fork很多的child子进程来处理connection,每一个子进程一次只能处理一个连接,并发度低,系统吞吐量不高。还有一个比较大的缺点是占用内存多。线程式处理软件结构如下图转载 2017-02-14 17:31:13 · 295 阅读 · 0 评论 -
设计杂谈
在设计时会碰到两种类型的设计,一种是框架级产品的设计,一种是项目产品的设计,在面向这两种进行设计时觉得还是非常不同的,框架级产品的设计强调一种通用性的抽象上,在这点上通常依赖开发或设计经验来进行抽象,难度不仅在此,通常框架级产品的设计都会面对技术性的问题,也就是说在设计阶段根本就是无法进行细化的一些部分,这种现象在框架级产品中通常出现,这时在进行设计时就要慎重考虑,通常按照敏捷工程的方法的话是先进行转载 2017-02-14 17:30:44 · 241 阅读 · 0 评论 -
系统设计之粒度控制
粒度这个词对于设计人员来说也不是什么陌生的词,粒度上通常称为粗粒度和细粒度,而这里讲的粒度控制主要指的是在系统设计的过程中如何根据需求去控制设计的范围。粒度的把握是软件设计的关键,举例子来说吧,目前软件的市场上充斥着各种各样同功能的软件,从功能来说甚至几乎完全一样的都有很多,但在各自粒度的控制上或者说达到的程度上都是不同的,往往可以看出大型软件公司做出来的东西虽然功能相同,但其在性能、伸缩性以及友转载 2017-02-14 17:30:14 · 1679 阅读 · 0 评论 -
系统设计之架构设计
架构设计这个词听的非常的多,但真正何谓架构设计呢??可能要你真的来讲还真的讲不太清楚,很多人都知道架构设计是对系统进行分层、分模块进行设计,但又有多少人知道这步应该怎么去做呢,往往很多的programmer在刚进入架构设计这个领域的时候,受到以前做模块的那种影响,把自己的眼光限定到了具体的模块实现上去了,并没有站在系统的高度上来把握系统的架构,这都是些理论性的话,来讲点实际的,^_^,具体架构设计指转载 2017-02-14 17:29:36 · 539 阅读 · 0 评论 -
设计高性能网站架构-LLMP
在网站架构设计中,大家一定对 LAMP (Linux Apache MySQL PHP) 不陌生。LAMP确实是一个非常优秀的架构,秉承着自由,开放,高效,易用的设计理念。但是,本文不打算探讨LAMP,网上有很多介绍LAMP的资料。这里,想给大家介绍另一个在LAMP上衍生出来的,以提升性能为主要目的的开源网站架构。1, 选择高性能 OS首先,不难理解,任何一个server最底层的支撑还是O转载 2017-02-14 17:29:11 · 272 阅读 · 0 评论 -
SOA并不能解决高并发事务
传统SOA架构其实无法面对高并发事务。 这种方式不适合热点资源,也就是高并发场合。虽然乐观锁短,但是容易产生脏数据。 SOA是以服务这个方式对外提供功能,我们很显然喜欢在Service中加上JTA等事务,比如EJB的无态Bean或Spring的@Transaction标注都是激活这样的功能,这种方式实际是一种悲观事务,容易引起死锁,特别是在高并发情况下。转载 2017-02-14 17:28:04 · 312 阅读 · 0 评论 -
Web请求异步化
这两天在继续了解web应用中的异步处理问题。然后看到了淘宝文初的博客http://blog.csdn.NET/cenwenchu79 ,他在几篇文章中多次提及jetty的continuation和servlet3的异步处理特性。看了之后收获不少。异步处理的层次异步处理在Web应用中可以分三个层次:Socket数据传输的异步化(NIO)HTTP请求的异步化(Jetty Continuation,S转载 2017-02-14 17:27:31 · 362 阅读 · 0 评论 -
用Unix的设计思想来应对多变的需求
无论是Unix设计,还是面向对象设计,还是别的什么如SOA,ECB,消息,事件,MVC,网络七层模型,数据库设计,等等,他们都在干三件事——解耦,解耦,还是解耦!所谓解耦,就是让软件的模块和模块间尽量少地依赖起来。现实当中的例子让我先举几个现实生活中的例子:1.现实社会中,制造灯具的工厂完全不关心制造灯泡的工厂,制造灯泡的工厂完全不关心制造灯具的工厂,但是,灯泡和灯饰可以很完美地组合成用记所喜转载 2017-02-14 17:27:02 · 217 阅读 · 0 评论 -
基于消息实现系统间的通信(BIO,NIO,AIO)
当系统之间要通信时,就向外发送消息,消息可以是字节流,字节数组,甚至是Java对象,其他系统接受消息后,则进行相应的业务处理。消息方式的系统间通信,通常基于网络协议来实现,常用的实现系统间的通信协议有:TCP/IP 和UDP/IP。TCP/IP是一种可靠的网络数据传输协议。TCP/IP要求通信双方首先建立连接(通过三次握手协议),之后再进行数据的传输。TCP/IP保证数据传输的可靠性,包括数据的转载 2017-02-14 17:33:04 · 263 阅读 · 0 评论 -
大型Java分布式应用纵横谈
在当今应用架构里,分布式和应用与服务之间的通信都是核心思想。想要从分布式中获益,你必须牢牢记住几条基本的原则,否则你可能会很容易遇到性能和扩展性问题。在开发阶段这些问题不会经常出现,但当你进行负载测试或产品化的时候,你可能会意识到你选择的软件架构不能满足性能和扩展性需求。在这篇文章中,我们重点关注构建分布式应用需要记住的一些关键点。 分布式需要应用之间进行交互。范围包括从大规模集群架转载 2017-02-14 17:33:50 · 340 阅读 · 0 评论 -
软件架构师应该知道的97件事
1. 客户需求重于个人简历不要为了学习新的知识或丰富自己的简历而选择新技术解决问题,要尽量选择切合实际的技术解决客户的难题。脚踏实地的为客户着想,选择正确的方案可以降低项目的压力,团队工作起来更开心,客户也会更满意,从而你也会有更充裕的时间学习新的知识。 2. 简化根本复杂性,消除偶发复杂性根本复杂性是问题本身就很复杂,所以它是无法避免的。偶发复杂性是在解决根本复杂性的过程中衍生的,即解决转载 2017-02-14 17:34:24 · 487 阅读 · 0 评论 -
Java软件架构设计简介
开始之初的架构设计决定着软件产品的生死存亡。“好的开始相当于成功一半”!开始的架构设计也是最难的,需要调研同类产品的情况以及技术特征,了解当前世界上对这种产品所能提供的理论支持和技术平台支持。再结合自己项目的特点(需要透彻的系统分析),才能逐步形成自己项目的架构蓝图。比如要开发网站引擎系统,就从Yahoo的个人主页生成工具 到虚拟主机商提供的网站自动生成系统,以及IBM Webphere Por转载 2017-02-14 17:39:46 · 321 阅读 · 0 评论 -
软件架构设计箴言理解
今天和师弟聊天聊到他们项目开发,有些同事总是提前考虑性能优化,需求变更又是一大堆的重写,让我想起了Donald Knuth 提到的:对软件的过早地优化是万恶的根源。这里就简单的说几条重要的软件名人哲学。1:软件中唯一不变的就是变化。在软件开发过程中需求是不停的变化,随着客户对系统的认识,和现有开发功能和软件的认识,也许以开始他提出的需求就是背离的。记得网上有一句笑话,师说需求变化的:程序员XX遭转载 2017-02-14 17:39:18 · 215 阅读 · 0 评论 -
大型网站架构不得不考虑的10个问题
本文以高负载高数据交换高数据流动性的网站为例,从架构的方面讲解了对如开心我、海内网等高互动性高交互性的数据型大型网站架构设计时需要注意的10个问题。 这里的大型网站架构只包括高互动性高交互性的数据型大型网站,基于大家众所周知的原因,我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了,我们以高负载高数据交换高数据流动性的网站为例,比如海内,开心网等类似的web2.0系列架构。我们这里不讨论转载 2017-02-14 17:38:49 · 163 阅读 · 0 评论 -
Google App Engine技术架构资料大盘点
今天看到几篇有关Google App Engine的技术架构文章,一起分享给大家,没看到过的同学赶紧惊喜一下吧,看到过了的同学也假装惊喜一下嘛,呵呵。全部文章有点长,请耐心看下去,相信程序员都是有耐心的,除了我…….一、Google的核心技术在切入Google App Engine之前,首先会对Google的核心技术和其整体架构进行分析,以帮助大家之后更好地理解Google App Engin转载 2017-02-14 17:38:24 · 574 阅读 · 0 评论 -
大型网站架构演变
之前也有一些介绍大型网站架构演变的文章,例如LiveJournal的、ebay的,都是非常值得参考的,不过感觉他们讲的更多的是每次演变的结果,而没有很详细的讲为什么需要做这样的演变,再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术,于是有了写这篇文章的想法,在这篇文章中将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系,希望能给想从事互联网行业转载 2017-02-14 17:37:56 · 194 阅读 · 0 评论 -
各大型网站架构分析收集
1. PlentyOfFish 网站架构学习http://www.dbanotes.net/arch/plentyoffish_arch.html采取 Windows 技术路线的 Web 2.0 站点并不多,除了 MySpace ,另外就是这个 PlentyOfFish。这个站点提供 “Online Dating” 服务。一个令人津津乐道的、惊人的数据是这个只有一个人(创建人Markus Frin转载 2017-02-14 17:37:24 · 239 阅读 · 0 评论 -
服务器端编程的十大性能问题
今年5月底,瑞士计算机世界杂志上刊登了Web性能诊断专家Bernd Greifeneder的一篇文章,文章列举了其在过去几年工作中所遇到的服务器端编程的十大性能问题。Andreas Grabner则在自己的博客上对这些性能问题给出了进一步阅读的链接。希望这些问题与相关的延伸阅读能为广大的InfoQ读者带来一定的启示。问题一:过多的数据库调用我们发现经常出现的一个问题就是在每次请求/事务中存在过转载 2017-02-14 17:36:59 · 382 阅读 · 0 评论 -
打造高可用,高可扩展的互联网平台
很多互联网公司早期初创,为了快速开发出应用产品,基本都是采用LAMP技术组合来搭建网站。由于开发人员也不是很多,所以采用在一个工程下开发,或者一个工程下的多模块开发。随着公司的业务和流量快速膨胀,人员规模也从数十人扩张到数百人,导致网站的开发,部署,运维带来很大的挑战: 1)众多开发人员围着一个工程开发,打包,测试,部署纠结在一起,互相等待,严重的影响了生产效率;转载 2017-02-14 17:36:36 · 439 阅读 · 0 评论 -
大型互联网网站架构心得之一:分
我们知道,对于一个大型网站来说,可伸缩性是非常重要的,怎么样在纵向和横向有良好的可伸缩性,就需要在做架构设计的时候考虑到一个分的原则,我想在多个方面说一下怎么分:首先是横向的分:1. 大的网站化解为多个小网站:当我们一个网站有多个功能的时候,可以考虑把这个网站拆分成几个小模块,每一个模块可以是一个网站,这样的话我们到时候就可以很灵活地去把这些网站部署到不同的服务器上。2. 静态动态分离:静态文转载 2017-02-14 17:35:50 · 224 阅读 · 0 评论 -
大型互联网网站架构心得之二:并、换
上次说的“分”是一个比较大的原则也是一个比较高层的原则,这次我想说一下其它两个原则:并与换。 并 为什么要分?是因为我们希望通过分来提高系统的承载能力,那并又是并什么呢?我想了一下有几个方面可以并: 1. 合并用户请求,最基本的就是合并CSS/图片/脚本,还可以合并页面。不过合并就可能产生流量的浪费,需要有一个平衡点。2. 合并接口的粒度,如果做分布式应用的话,转载 2017-02-14 17:35:24 · 451 阅读 · 0 评论 -
高并发大型网站架构设计
一个大型的网站网站应该由如下6个子系统组成 负载均衡系统反向代理系统Web服务器系统分布式存储系统底层服务系统数据库集群系统 为什么要做高并发系统设计?事实上,针对于任何单一的网络服务器程序,其可承受的同时连接数目是有理论峰值的,通过C++中对TSocket的定义类型:word,我们可以判定这个连接理论峰值是65535,也就是说,你的单个服务器程序,最多可以承受6万多的用户同时转载 2017-02-14 17:34:55 · 367 阅读 · 0 评论 -
从实例中理解框架
目前,各种开发框架非常流行,那么,什么是框架(Framework)?框架是如何产生的?为什么要使用框架,以及使用框架能给我们的开发带来什么样的好处呢?下面就以我们熟悉的web框架为基础来加深对框架的理解。 在不使用Struts或者SpringMVC等web层框架时,一直是由Servlet完成业务逻辑的实现,但是,随着Servlet的增多,web.xml的配置会不断的膨胀,从而变得难以维转载 2017-02-14 17:26:25 · 191 阅读 · 0 评论 -
Leader/Follower线程模型
近来正在分析线程模型,先写上最经典的Leader/Follower模式,代码是论坛里面一位兄弟写的,我主要是分析了一下,看一下实现,也顺便把类图贴上。转载 2017-02-14 17:25:53 · 282 阅读 · 0 评论 -
互联网系统架构的演进
多终端接入、开放平台给互联网带来了前所未有的用户量级和访问规模,SNS网站产生了海量的UGC(用户产生内容),而且这些内容依托关 系链扩散速度之快、传播范围之广是传统网站难以想象的,海量数据的计算存储也一直是近年互联网领域的热点。本文将从发展演进的层面探讨互联网的系统架构。天下武功唯快不破网站初期的架构一般采用“短平快”的架构思路,架构以简单清晰、容易开发为第一衡量指标。互联网架构选型首先包括开发语转载 2017-02-14 17:03:39 · 309 阅读 · 0 评论 -
中大型移动互联网公司技术架构选择
总体思考总结这些年经验,进行构架演进的方向选择时,大致要做到下面的目标:可快速开发部署 (五分钟写出来一个经过测试的hello world并可访问/调用,并可在公网访问)天然可扩展(业务层无状态,尽可能全部放到最后)自动化(内存不足了,除了报警,应该自动加点机器进去; 新的项目,基础代码应该都不用写,自动生成即可)框架化(公共层面的东西尽可能框架化,一层类似日志、counter、trace,转载 2017-02-14 17:02:18 · 1057 阅读 · 0 评论 -
Google服务器架构图解简析
Google,无疑是互联网时代最闪亮的明星。截止到今天为止,Google美国主站在Alexa排名已经连续3年第一,Alexa Top100中,各国的Google分站竟然霸占了超过20多个名额,不得不令人感叹Google的强大。不论何时,不论何地,也不论你搜索多么冷门的词汇,只要你的电脑连接互联网,只要你轻轻点击“google搜索”,那么这一切相关内容google都会在1秒钟之内全部搞定,这甚至比你转载 2017-02-14 17:01:33 · 567 阅读 · 0 评论 -
互联网系统的架构设计必须要考虑的关键点
前两天听了海量用户服务系列课后,收获颇多,快速整理下思路,几个基本点:一,互联网产品是一个运营的产品,产品的成功很大程度上是运营出来的,而不是开发出来的,从产品的生命周期看,开发环节只是占了其中的一小部分,而产品的生命周期大部分是处于运营状态,因此,在架构设计阶段就必须把产品的可运营性纳入到设计的重要思考点,而绝对不是简单的实现一个功能点就大功告成了。 二,什么是可运营的产品?产品的运营是一个动态调转载 2017-02-14 17:00:45 · 324 阅读 · 0 评论 -
互联网架构设计的几个原则
一,可(异地)部署和就近路由接入,破除单点故障; (可分布,可调度的原则) 二,数据上报和监控平台; (用户行为数据,系统性能监控数据,系统异常和业务相关数据等的上报) 三,数据分级存储原则:单内存cache存储,内存cache+异步更新,内存cache+同步更新; (从三个纬度分析用户行为模型,决定相关数据的存储策略:1,能忍受用户数据的丢失吗?2,能忍受数据的非及时转载 2017-02-14 16:55:35 · 728 阅读 · 0 评论 -
微信架构的启示
腾讯大讲堂中最近分享了周颢演讲的微信技术总监解读微信架构的秘密,看完视频的一些心得。技术微创新微信的技术设计上有很多微创新,看起来都很小,但是对于系统的稳定性、用户体验及开发敏捷都具有重要作用。前轻后重由于客户端升级不便,从技术设计上尽量利用后端的设计来减少依赖客户端升级的方法。如某个版本新增了群聊功能,按常规思路,需要所有客户端升级才能全部打通。微信采用服务器兼容的方法,在老客户端不升级情转载 2017-02-14 16:54:14 · 323 阅读 · 0 评论 -
Amazon Dynamo论文解读 - Merkle Tree的使用
Merkle Tree是Dynamo论文中用到的一个算法,读这篇论文前,我并不知道这个算法,所以找了相关资料了解了解,以便我对论文有更进一步的了解。 什么是Merkle Tree Merkle Tree,是一种树(数据结构中所说的树),网上大都称为Merkle Hash Tree,这是因为 它所构造的Merkle Tree的所有节点都是Hash值。Merkle Tree具有以下特点:转载 2017-02-14 16:51:22 · 277 阅读 · 0 评论 -
解读NoSQL技术代表之作Dynamo
NoSQL在过去的一年里,逐渐已经成为了家喻户晓的东西,我(54chen)自从去年开始人人网的NoSQL系统Nuclear的研发以来,一直看NoSQL越来越热,越来越引来大家的围观。受InfoQ中文站编辑之托,特作此文,一来作为过去一年的总结,二来希望对NoSQL系统在国内的发展和推广尽绵薄之力。NoSQL背后的两种模式NoSQL其实并不是什么妖魔鬼怪,相反,NoSQL的真谛其实应该是Not Onl转载 2017-02-14 16:30:27 · 242 阅读 · 0 评论 -
服务管理框架的尝试
大型软件系统开发需要模块化,在分布式系统中,模块化通常是将功能分成不同的远程服务(RPC)来实现。比如可以用Java RMI、Web Service、Facebook开源的Thrift等一些技术。同样,在一个大型系统中,服务化之后服务的可维护、可管理、可监控以及高可用、负载均衡等因素同服务本身同样重要。服务管理目前并无直接解决方案,如果开发一个自己的服务管理框架,需要具备以下功能快速失败,这个在本厂转载 2017-02-14 16:29:44 · 187 阅读 · 0 评论 -
面向海量服务的设计原则和策略总结
面向海量服务的设计原则和策略总结 互联网服务的特点就是面向海量级的用户,面向海量级的用户如何提供稳定的服务呢?这里,对这几年的一些经验积累和平时接触的一些理念做一个总结。 一、原则 1.Web服务的CAP原理 CAP指的是三个要素:一致性(Consistency)、可用性(Availability)、分区容忍性(Partition tolerance)转载 2017-02-14 14:23:41 · 228 阅读 · 0 评论 -
服务器端开发技术
1. 多进程或多线程模型多进程服务器:Apache,Nginx,lighttpd等服务器均为多进程模型,分为Master进程和Woker进程多进程的优点:更强的容错性 - 一个进程挂掉不会导致整个系统崩溃,更好的多核可伸缩性 - 进程的使用将许多内核资源(如地址空间,页表,打开的文件)隔离,在多核系统上的可伸缩性强于多线程程序。多线程服务器:Tomcat,Netty等服务器均为多线程模型,分为转载 2017-02-14 14:22:59 · 365 阅读 · 0 评论 -
Protocol Buffer技术详解(语言规范)
该系列Blog的内容主体主要源自于Protocol Buffer的官方文档,而代码示例则抽取于当前正在开发的一个公司内部项目的Demo。这样做的目的主要在于不仅可以保持Google文档的良好风格和系统性,同时再结合一些比较实用和通用的用例,这样就更加便于公司内部的培训,以及和广大网友的技术交流。需要说明的是,Blog的内容并非line by line的翻译,其中包含一些经验性总结,与此同时,对于一些转载 2017-02-14 17:06:53 · 310 阅读 · 0 评论