随笔分类 -  架构师

摘要：提高服务器响应能力的方法scale on 在原有服务器的基础上进行升级或者直接换一台新的性能更高的服务器。scale out 横向扩展，将多台服务器并发向外响应客户端的请求。优点：成本低，扩展架构比较简单。集群（Cluster），通俗地讲就是按照某种组织方式将几台电脑组织起来完成某种特定任务的这样一种架构。三种集群类型：LB，Load Balancing 负载均衡：在一定程度上能够实现高可用的目的。HA，High Availability 高可用：实时在线，能够及时响应客户端请求，企业应用要求达到 7*24小时，99.999%时间在线。HP，High Performance 高性能 提供大量超 阅读全文

摘要：Linux下集群服务简介：ClusterLB:Load Balancing,负载均衡HA：High Availability ，高可用HP：High Performance，高性能负载均衡集群目的是提供和节点个数成正比的负载能力，这种集群很适合提供大访问 量的Web服务。负载均衡集群往往也具有一定的高可用性特点。高可用性集群运行于两个或多个节点上，目的是在系统出现某些故障的情况下，仍能继续对外提供服务。高可用性集群的设计思想就是要最大限度地减少服务中断时间。这类集群中比较著名的有Turbolinux TurboHA、Heartbeat、Kimberlite等。高性能集群对一种服务而言不具有负载 阅读全文

摘要：大家下午好，在座的大部分都是技术开发者，技术开发者往往对微博这个产品非常关心。最晚的一次，是12点多收到一个邮件说想了解一下微博底层是怎么构架的。很多技术人员对微博的构架非常感兴趣，就是一个明星他有300万粉丝，这个技术怎么来实现？今天在这里跟大家分享一下微博的底层机构，让大家对微博的底层技术有更好的了解。另外不管是做客户端、Web 1.0、Web 2.0、论坛、博客都要考虑架构的问题，架构实际上是有一些共性的。今天我通过讲解微博里面的一些架构，分析一下架构里面哪些共性大家可以参考。 首先给大家介绍一下微博架构发展的历程。新浪微博在短短一年时间内从零发展到五千万用户，我们的基层架构也发展了3. 阅读全文

摘要：简而言之，没有哪个模式是一个孤立的个体。每个模式都只有靠与其他模式相互支持才得以存在于世界之中；每个模式都嵌入到更大的模式里，被同样大小的模式环绕，并且还有更小的模式嵌入在它的内部----这也就是所谓”相互支持“的意思。 -----Christopher Alexander 阅读全文

摘要：1.前言本文的目的是让一个从未接触Hadoop的人，在很短的时间内快速上手，掌握编译、安装和简单的使用。2.Hadoop家族截止2009-8-19日，整个Hadoop家族由以下几个子项目组成：成员名用途Hadoop CommonHadoop体系最底层的一个模块，为Hadoop各子项目提供各种工具，如：配置文件和日志操作等。AvroAvro是doug cutting主持的RPC项目，有点类似Google的protobuf和Facebook的thrift。avro用来做以后hadoop的RPC，使hadoop的RPC模块通信速度更快、数据结构更紧凑。ChukwaChukwa是基于Hadoop的大集 阅读全文

摘要：架构师特质：能够帮助团队的同事解决问题，参与项目和产品设计对于公司的产品和项目发展方向有清晰的认知常常思考企业产品和项目的方向对公司产生的价值跟业务人员有良好的沟通，善于发掘需求具备很广的知识面，不一定要很深入大局观、开放心态和善于沟通复杂问题简单化的抽象能力架构师分类：基础平台架构师业务架构师数据架构师架构师的职责：平衡平衡需求和条件、平衡性能和功能、平衡需求和成本一致确保需求的一致性；取保产品规划、产品线架构规划和本产品架构与设计的一致；确保客户需求、架构约束、设计准则在实施阶段得到一致贯彻分解将系统分解成子系统；将子系统分解成模块；将模块分解成类设计集成将功能上的分解与系统性能和质量上的 阅读全文

摘要：架构师是个很需要沟通技巧的角色，需要和老板沟通，使其相信在技术上的可行性；需要和PD沟通，弄清楚商业逻辑；需要和项目经理沟通，使其更科学地安排人员和进度；需要和开发人员沟通，使其理解设计思路，保障设计架构在具体实施中得以落实；需要和QA沟通，使其了解项目的风险点和关键点。因此，架构师需要在沟通上下功夫，这是保障工作顺利进行的关键环节。下面是我总结的几个很常用的沟通方式：挑衅式的沟通方式具体方法：在矛盾双方中，以其中一方比较极端的观点来合理地构想后果，然后将这样的后果与另外一方进行沟通，激发另外一方去思考这种构想的后果，提出自己意见。适用场景：争论双方陷入僵局。适应式的沟通方式具体方法：确定主题 阅读全文

摘要：经历过大 规模架构重构（ReArchitecture）的同学都知道：ReArchitecture是一个极其痛苦的过程，要想将原有的working的代码，彻底地用新的架构，新的技术 重新写一遍，其工作量是令人望而生畏的。最复杂的莫过于业务逻辑的梳理，如果你有精力将原有的代码从头读一遍，那是最lucky的事，但大多数情况下，别人写的代码 需要你自己重新写一遍，大多数人没有精力或不愿意去通读代码，而主要依赖于需求文档，结合旧代码，写出新的代码。但需求文档的更新永远赶不上代码的更新速 度，你得期盼原先写这个代码的同学有很好的习惯，将变更的需求反映在文档中，而且代码中有很好的注释。基本上这种情况很少见。 阅读全文

摘要：最近参加公司内一个技术规划评审过程中，通过老板对台上的架构师的质疑，学习到几个做技术规划的要点，归纳如下：1）紧扣业务虽然是做技术规划，但如果脱离了业务支撑，是引起不了老板兴趣的2）从实际问题出发老板只会为解决实际问题的技术规划买单。规划的开头最好能从实际问题出发，比较容易引起老板的注意3）重点在落地只有能落地的技术才有说服力，老板不会被天花乱坠的技术词汇给迷惑的，他只会关注最后能落地是哪几项，应该重点谈落地的目标和计划4）突出关键点和关键路径其中一个哥们说了很多，非常丰富，但关键点不突出，结果在老板看来就是个零。在表述规划的整个过程中，一定要紧扣关键旋律，让老板用最短的时间理解你的意图5）少 阅读全文

摘要：原则大于个人口味很多架构师都有着丰富的经验和个人风格，以至于在平常工作中常以个人口味作为决策的依据，对于普通的开发人员也许是可行的，我们鼓励大家有个人特色，但架构师更应该依据原则办事，需要维护和遵守一套大家公认的原则，以此作为判断是非的工具从“可行走骨架”开始敏捷管理崇尚尽早集成，在架构设计这一块，这个原则也行之有效。架构师在开始阶段无需陷入某些难题或细节里，应该尽快地把各个核心模块串接起来，并能发动开发人员使其简单地运转起来，骨架一旦就绪，再进入健身环节。这样做的好处，一方面可以尽早消除大家之间的误解，也可以带来正朝着正确方向前进的信心数据是核心数据为王是大家深知的道理，只要这个系统拥有有价 阅读全文

摘要：让开发人员自己做主架构师虽然需要为系统的设计负责，但无须包揽所有的设计工作，应该给予团队成员足够的自主权，让他们发挥自己的创意和能力，你的工作是确保大家的工作能很好的组合在一起，帮助他人解决棘手困难。当你发现同事遇到麻烦时，可以主动给出建议，但更可取的做法是创造良好的氛围，让大家主动向你征求意见。控制项目规模架构师要试图避免做那种“超大型”系统，因为这种系统往往难以控制，控制项目规模的办法通常有：抓住真正需求分而治之设置优先级尽快交付原则架构师不是演员，而是管家有些架构师误解了证明自己价值的含义，以为是炫耀技术才华，甚至是***难开发团队，把自己放在高高在上的位子，试图让别人来崇拜你。其实架构师的 阅读全文

摘要：先确保解决方案简单可用，再考虑通用性和复用性系统的复杂性往往是架构师基于通用性和复用性的设计而引入的，很多具体问题往往不需要通用性和复用性的解决方案。如果存在多个可实施方案难以取舍，先简单后通用原则可以成为最终的评判标准。架构师提供具体解决方案时，无需排斥通用和灵活，但是如果过早脱离具体情况，只会迷失在无限的可能性里，被复杂的配置选项、超负荷的参数列表、冗长罗嗦的接口，以及存在缺陷的抽象所淹没。先简单满足需求，当重复需求再次发生时，通过重构来达到复用是一种不错的方式架构师应该亲力亲为架构师干久了往往会脱离技术本身，迷茫在抽象之中，这是很危险可怕的。架构师要取得其他同事的信任，应该比业务人员更懂 阅读全文

摘要：最近看了一本书《软件架构师应该知道的97件事》，本来并没对它抱有太多期望和兴趣，毕竟这种讲大道理的书不可能带来什么实际收获，但看的过程中被里面中肯实在的建议给吸引，对于我这种在走向架构师这条路上常常迷失方向的人，实在是雪中送炭。读完后，决定选择其中对我有触动的条目，加上实际工作中的感悟，形成一套自认为正确的架构师行为准则，以此来矫正自己的行为。客户需求高于一切不要为了自己的项目经历上添加光彩而去一味追求时髦而光鲜的方案，而是应该扎根客户需求，脚踏实地地为客户着想，这样才能更体现技术的价值，不至于迷失方向。架构师首先不要把自己当做技术人员，而是业务人员，把实现业务需求作为至上的目标，学会拒绝成本 阅读全文