湖北网站建设找哪家,网站主机设置方法,建设医院网站的重点与难点在于,网站设计的价格本文作者叫Srinath#xff0c;是一位科学家#xff0c;软件架构师#xff0c;也是一名在分布式系统上工作的程序员。他是Apache Axis2项目的联合创始人#xff0c;也是Apache Software基金会的成员。他是WSO2流处理器#xff08;wso2.com/analytics#xff09;的联席架构…本文作者叫Srinath是一位科学家软件架构师也是一名在分布式系统上工作的程序员。他是Apache Axis2项目的联合创始人也是Apache Software基金会的成员。他是WSO2流处理器wso2.com/analytics的联席架构师。Srinath撰写了两本关于MapReduce和许多技术文章的书。他获得了博士学位。来自美国印第安纳大学。
Srinath通过不懈的努力最终总结出了30条架构原则他主张架构师的角色应该由开发团队本身去扮演而不是专门有个架构师团队或部门。Srinath认为架构师应该扮演的角色是一个引导者讨论发起者花草修建者而不是定义者和构建者。Srinath为了解决团队内部的架构纷争和抉择制定了以下30条原则这些原则被成员们广泛认可也成为了新手架构师的学习途径。
— 1 —
基本原则 原则1KISSKeep it simple, sutpid保持每件事情都尽可能的简单。用最简单的解决方案来解决问题。
原则2YAGNIYou aren’t gonna need it不要去搞一些不需要的东西需要的时候再搞吧。
点评speculative development的例子可谓俯拾皆是。程序员们对自己说“我肯定以后会需要这项额外的功能所以现在就提前把它实现了吧”。其实这是最考验功力的地方不能闭门YY需要的功能架构上又要洞察趋势。
原则3爬走跑。换句话说就是先保证跑通然后再优化变得更好然后继续优化让其变得伟大。迭代着去做事情敏捷开发的思路。对于每个功能点创建里程碑最大两周然后去迭代。
点评快速反馈一个“拍脑袋的里程碑”也好过没有里程碑……
原则4创建稳定、高质量的产品的唯一方法就是自动化测试。所有的都可以自动化当你设计时不妨想想这一点。
点评一切自动化也要考虑ROI比如对于特别易变的页面层……
原则5时刻要想投入产出比ROI。就是划得来不。
原则6了解你的用户然后基于此来平衡你需要做哪些事情。不要花了几个月时间做了一个DevOps用户界面最后你发现那些人只喜欢命令行。此原则是原则5的一个具体表现。
原则7设计和测试一个功能得尽可能的独立。当你做设计时应该想想这一条。从长远来看这能给你解决很多问题否则你的功能只能等待系统其他所有的功能都就绪了才能测试这显然很不好。有了这个原则你的版本将会更加的顺畅。
原则8不要搞花哨的。我们都喜欢高端炫酷的设计。最后我们搞了很多功能和解决方案到我们的架构中然后这些东西根本不会被用到。
点评老板喜欢PPT — 2 —
功能选择 原则9不可能预测到用户将会如何使用我们的产品。所以要拥抱MVPMinimal Viable Product最小可运行版本。这个观点主要思想就是你挑几个很少的使用场景然后把它搞出来然后发布上线让用户使用然后基于体验和用户反馈再决定下一步要做什么。
原则10尽可能的做较少的功能。当有疑问的时候就不要去做甚至干掉。很多功能从来不会被使用。最多留个扩展点就够了。
点评产品经理可能是听不进去的最好采取数据度量说话……
原则11等到有人提出再说除非是影响核心流程否则就等到需要的时候再去做。
原则12有时候你要有勇气和客户说不。这时候你需要找到一个更好的解决方案来去解决。记住亨利福特曾经说过的“如果我问人们他们需要什么他们会说我需要一匹速度更快的马”。记住你是那个专家你要去引导和领导。要去做正确的事情而不是流行的事情。最终用户会感谢你为他们提供了汽车。 — 3 —
服务端设计和并发 原则13要知道一个server是如何运行的从硬件到操作系统直到编程语言。优化IO调用的数量是你通往最好架构的首选之路。
原则14要了解Amdhal同步定律。在线程之间共享可变数据会让你的程序变慢。只在必要的时候才去使用并发的数据结构只在必须使用同步synchronization的时候才去使用同步。如果要用锁也要确保尽可能少的时间去hold住锁。如果要在加锁后做一些事情要确保自己在锁内会做哪些事情。
原则15如果你的设计是一个无阻塞且事件驱动的架构那么千万不要阻塞线程或者在这些线程中做一些IO操作如果你做了你的系统会慢的像骡子一样。 — 4 —
分布式系统 原则16无状态的系统的是可扩展的和直接的。任何时候都要考虑这一点不要搞个不可扩展的有状态的东东出来这是起码的。
原则17保证消息只被传递一次不管失败这很难除非你要在客户端和服务端都做控制。试着让你的系统更轻便使用原则18。你要知道大部分的承诺exactly-once-delivery的系统都是做了精简的。
原则18实现一个操作尽可能的幂等。这样的话就比较好恢复而且你还处于至少一次传递at least once delivery的状态。
原则19知道CAP理论。可扩展的事务分布式事务是很难的。如果可能的的话尽可能的使用补偿机制。RDBMS事务是无法扩展的。
点评new SQL了解一下……
原则20分布式一致性无法扩展也无法进行组通信也无法进行集群范围内的可靠通信。理想情况下最大的节点限制为8个节点。
原则21在分布式系统中你永远无法避免延迟和失败。
点评嗯对面向fail设计。但是你的考虑你的用户你的服务提供SLA。是真的需要724365吗
— 5 —
用户体验 原则22要了解你的用户和清楚他们的目标。他们是新手、专家还是偶然的用户他们了解计算机科学的程度。极客喜欢扩展点开发者喜欢示例和脚本而普通人则喜欢UI。
原则23最好的产品是不需要产品手册的。
原则24当你无法在两个选择中做决定的时候请不要直接把这个问题通过提供配置选项的方式传递给用户。这样只能让用户更加的发懵。如果连你这个专家都无法选择的情况下交给一个比你了解的还少的人这样合适吗最好的做法的是每次都找到一个可行的选项次好的做法是自动的给出选项第三好的做法是增加一个配置参数然后设置一个合理的默认值。
原则25总是要为配置设置一个合理的默认值。
原则26设计不良的配置会造成一些困扰。应该总是为配置提供一些示例值。
原则27配置值必须是用户能够理解和直接填写的。比如不能让用户填写最大缓存条目的数量而是应该让用户填写可被用于缓存的最大内存。
原则28如果输入了未知的配置要抛出错误。永远不要悄悄的忽略。悄悄的忽略配置错误往往是找bug花了数小时的罪魁祸首。
— 6 —
艰难的问题 原则29梦想着新的编程语言就会变得简单和明了但往往要想真正掌握会很难。不要轻易的去换编程语言。
点评“技术极客”是听不进去的不如把“个人修炼”和“项目采用”分开看待……
原则30复杂的拖拉拽的界面是艰难的不要去尝试这样的效果除非你准备好了10人年的团队。
点评我一直不太相信整体性的代码生成比如MDA或者拖拉拽建模代替写代码……如果说有成功的或者是在比较狭小的领域。
最后说一个我的感受。在一个理想的世界里一个平台应该是有多个正交组件组成-每个组件都负责一个方面比如securitymessagingregistrymdidationanalytics。好像一个系统构建成这样才是完美的。
但不幸的是现实中我们很难达到这样的状态。因为在项目初始状态时很多事情是不确定的你无法做到这样的独立性现在我更倾向于在开始的时候适当的重复是必要的当你尝试铲除他们的时候你会发现引入了新的复杂性分布本身就意味着复杂。有时候治愈的过程要比疾病本身更加的糟糕。
点评不同阶段采用不同的做法照抄往往会东施效颦。
— 7 —
总结 作为一个架构师应该像园丁一般更多的是修剪花草除草而不是去定义和构建你应该策划而不是指挥你应该去修剪而不是去定义应该是讨论而不是贴标签。虽然在短期内可能会觉得也没什么但从长远看指导团队找到自己的方式会带来好处。
如果你稍不留神就很容易让架构成为一个空洞的词汇。比如设计者会说他的架构是错误的但不知道为什么是错误的。一个避免这种情况的好办法就是有一个原则列表这个原则列表是被广泛接受的这个列表是人们讨论问题的锚点也是新手架构师学习的路径。
