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