作者介绍了Srinath，一位科学家，一位软件架构师。ApacheAxis2项目的联合创始人、Apache软件基金会成员和WSO2流处理器(wso2.com/analytics)的联合架构师。通过不懈努力，Srinath最终总结出30条架构原则。他主张架构师的角色应该由开发团队自己来扮演，而不是有一个专门的架构师团队或部门。Srinath认为，建筑师的角色应该是引导者、讨论发起者和花草的建设者，而不是定义者和建设者。为了解决团队内部的架构争议和选择，Srinath制定了以下30条原则。这些原则得到会员的广泛认可，成为新手架构师的学习路径。1.基本原则原则1KISS（Keepitsimple,sutpid），让一切尽可能简单。用最简单的方法解决问题。原则2YAGNI（你不会需要它），不要做你不需要的事情，在你需要的时候做。原则3爬、走、跑。换句话说，首先确保它运行流畅，然后优化它变得更好，然后继续优化它让它??变得更好。迭代地做事，敏捷开发的思想。对于每个功能点，创建里程碑（最多两周），然后迭代。原则4创建稳定、高质量产品的唯一方法是通过自动化测试。一切都可以自动化，所以在设计时请记住这一点。原则5时刻想着投入产出比（ROI），即是否值得。原则6了解您的用户，然后根据此平衡您需要做的事情。不要花数月时间构建一个devopsUI，却发现那些人只喜欢命令行。这个原则是原则5的具体体现。原则7尽可能独立地设计和测试一个功能。当你设计的时候，你应该考虑到这一点。从长远来看，这可以为你解决很多问题，否则你的功能只能在系统所有其他功能都准备就绪时才能测试，这显然不好。有了这个原则，你的版本就会更流畅。原则8不要花哨。我们都喜欢高端酷炫的设计。我们最终在我们的架构中加入了很多功能和解决方案，然后这些东西根本就没有被使用过。2.功能选择原则9用户将如何使用我们的产品是无法预测的。所以拥抱MVP（最小可行产品），最小可运行版本。这个观点的主要思想是，你挑几个使用场景，然后做出来，然后发布到网上供用户使用，然后根据体验和用户反馈来决定下一步怎么做。原则10做尽可能少的功能。如有疑问，请不要这样做，甚至不要杀死它。许多功能从未使用过。最多留一个扩展点就够了。原则11等到有人提出来（除非它影响核心流程，等到你需要的时候）。原则12有时你必须鼓起勇气对客户说不。这时候就需要寻找更好的方案来解决了。记住亨利福特曾经说过的话：“如果我问人们他们想要什么，他们会说我需要一匹更快的马”。请记住：您是专家，引导和领导全靠您。做正确的事，而不是流行的事。最终用户会感谢您为他们提供汽车。3.服务器设计和并发原则13您需要了解服务器的工作原理，从硬件到操作系统再到编程语言。优化IO调用的数量是获得最佳架构的第一条途径。原则14是了解阿姆达尔同步定律。在线程之间共享可变数据会减慢你的程序。仅在必要时使用并发数据结构，仅在必须时才使用同步。如果您想使用锁，请确保尽可能少地持有锁。如果你想在锁定后做某事，请确保你将在锁内做什么。原则15如果你的设计是非阻塞和事件驱动的架构，那么永远不要阻塞线程或者在这些线程中做一些IO操作，如果你这样做，你的系统会像骡子一样慢。4.分布式系统原则16无状态系统具有可扩展性和直接性。你应该随时考虑这个，不要想出一个不可扩展的，有状态的东西，这是最低限度的。原则17保证消息只传递一次，无论是否失败，除非您想同时控制客户端和服务器，否则很难做到这一点。尽量让你的系统更轻（使用原则18）。您需要知道，大多数承诺一次交付的系统都是精简的。原则18使操作尽可能幂等。这种情况下比较容易恢复，你还是处于至少一次投递的状态。原则19了解CAP理论。可扩展事务（分布式事务）很难。尽可能使用补偿机制。RDBMS事务不可扩展。原则20分布式共识无法扩展，群组通信也无法实现，集群范围内的可靠通信也无法实现。理想情况下，最大节点限制为8个节点。原则21在分布式系统中，你永远无法避免延迟和故障。五、用户体验原则22了解你的用户并明确他们的目标。他们是新手、专家还是临时用户？他们对计算机科学的了解程度。极客喜欢扩展点，开发人员喜欢示例和脚本，普通人喜欢UI。原则23最好的产品不需要产品手册。原则24当您无法在两种选择之间做出决定时，不要通过提供配置选项将问题直接传递给用户。这只会让用户更加困惑。如果你这个专家无法选择，那么把它交给比你了解得少的人合适吗？最好的方法是每次都找到一个可行的方案；第二好的方法是自动给选项，第三好的方法是添加一个配置参数并设置一个合理的默认值。原则25始终为配置设置一个合理的默认值。原则26设计不当的配置会引起一些混乱。配置应始终提供一些示例值。原则27配置值必须是用户可以理解和直接填写的。例如：不是让用户填写最大缓存条目数，而是应该允许用户填写可用于缓存的最大内存.原则28如果输入未知配置则抛出错误。永远不要悄悄忽视。悄悄地忽略配置错误通常是花费数小时寻找错误的罪魁祸首。6.难题原则29梦想一门新的编程语言会变得简单明了，但真正掌握它往往很难。不要轻易改变编程语言。原则30复杂的拖放界面很难，除非你准备好迎接一个10人年的团队，否则不要尝试它们。最后说一下我的感受吧。在一个理想的世界中，一个平台将由多个正交组件组成——每个组件负责一个方面（例如，安全、消息传递、注册、决策、分析）。好像这样构建的系统就完美了。但遗憾的是，在现实中，我们很难达到这样的境界。因为在项目的初始状态，很多事情都是不确定的，你无法做到这样的独立，现在我更倾向于在开始的时候适当的重复，当你尝试去根除它们的时候，你会发现一个新的层次引入了复杂性，分布本身就意味着复杂性。有时愈合过程比疾病本身更糟糕。7.小结作为一名建筑师，你应该像一名园丁。你应该修剪花草，而不是定义和建造。你应该计划而不是命令，你应该修剪而不是定义，你应该讨论而不是标签。虽然短期内可能感觉不错，但从长远来看，引导团队找到自己的方式将会带来回报。如果你不小心，建筑很容易变成一个空洞的词汇。比如设计师会说他的架构是错误的，但是他不知道为什么会错。避免这种情况的一个好方法是有一个被广泛接受的原则列表，这个列表是人们讨论问题的锚点，也是新手架构师的学习路径。
