无处不在,搜你所想

作者是Srinath，一位科学家、软件架构师和分布式系统程序员。他是Apache Axis2项目的联合创始人和Apache软件基金会的成员。他是WSO2流处理器(wso2.com/analytics)的联合架构师。Srinath写了两本关于MapReduce的书和许多技术文章。他获得了博士学位。来自印第安纳大学。

经过不懈的努力，Srinath最终总结出了30条建筑原则。他主张架构师的角色应该由开发团队本身来扮演，而不是由架构师团队或部门来扮演。Srinath认为架构师应该扮演的角色是领导者、讨论发起者、花构建者，而不是定义者和构建者。为了解决团队内部的结构纠纷和选择，Srinath制定了以下30条原则，得到了团队成员的广泛认可，成为了新手建筑师的学习路径。

原则1：KISS(Keep it simple,sutpid)让一切尽可能的简单。用最简单的方法解决问题。

原则2：YAGNI(You aren’t gonna need it)-不要做你不需要的事，需要的时候再去做。

原则3：爬，走，跑。换句话说就是先保证跑通，然后再优化变得更好，然后继续优化让其变得伟大。迭代着去做事情，敏捷开发的思路。对于每个功能点，创建里程碑（最大两周），然后去迭代。

原则4：创建稳定、高质量产品的唯一方法是自动化测试。一切都可以自动化，所以在设计时要考虑这一点。

原则5：总是想要投资于产出比率(ROI)。这件事值不值得。

原则6：了解你的用户，然后在此基础上平衡你需要做的事情。不要花几个月的时间来开发devops用户界面，最后你会发现这些人只喜欢命令行。这一原则是原则5的具体体现。

原则7：尽可能独立地设计和测试一个函数。当你做设计的时候，你应该考虑这个。从长远来看，这可以为您解决很多问题，否则您的函数只能等待系统的所有其他函数准备好测试，这显然是非常糟糕的。有了这个原则，您的版本将更流畅。

原则8：不要幻想。我们都喜欢高端酷炫的设计。最后，我们在我们的架构中做了很多功能和解决方案，然后这些东西就不再使用了。

原则9：

无法预测用户将如何使用我们的产品。所以拥抱MVP(最小可行产品)，最小的可运行版本。这一点的主要思想是，您选择几个使用场景，然后将其取出，然后将其发布给用户使用，然后根据体验和用户反馈决定下一步要做什么。

原则10：尽可能少地执行功能。如果有疑问，不要做，甚至不要杀了它。许多功能从未使用过。最多只留下一个扩展点就足够了。

原则11：等到有人问起(除非影响到核心流程，否则等到需要的时候)。

原则12：有时候你有勇气对你的客户说不。此时，您需要找到一个更好的解决方案。记得亨利·福特曾经说过:“如果我问人们他们需要什么，他们会说我需要一匹更快的马。”记住:你是专家，你必须引导别人。做正确的事，而不是受欢迎的事。最终用户将感谢您为他们提供了一辆汽车。

原则13：了解服务器如何工作，从硬件到操作系统，再到编程语言。优化IO调用的数量是最佳架构的首选。

原则14：理解阿姆达尔同步定律。线程之间共享变量数据会降低程序运行速度。只有在必要时才使用并发数据结构，只有在必须使用同步时才使用同步。如果你想使用一把锁，一定要尽可能少地握住它。如果你想在上锁后做些什么，确保你在锁里做了什么。

原则15：

如果您的设计是非阻塞和事件驱动的体系结构，那么不要阻塞线程或在这些线程中执行一些IO操作。如果你这样做，你的系统将会像骰子一样慢。

原则16：

无状态系统是可伸缩的，并且很简单。你应该一直考虑这个问题。不要做不可扩展的、有状态的东西。至少是这样。

原则17：确保消息只传递一次，不管发生什么故障，这是很困难的，除非您想同时在客户机和服务器上进行控制。试着让你的系统更轻(使用原则18)。您必须知道，大多数承诺的精确一次交付系统都经过了精简。

原则18：

尽可能地执行一个操作。在这种情况下，最好是恢复，并且您仍然至少在一次交付中。

原则19：了解上限理论。可扩展事务(分布式事务)比较困难。如果可能，尽可能使用补偿机制。无法扩展RDBMS事务。

原则20：

不能扩展分布式一致性，不能进行组通信，不能在集群内进行可靠的通信。理想情况下，最大的节点限制为8个节点。

原则21：在分布式系统中，您永远无法避免延迟和失败。

原则22：

了解你的用户，明确他们的目标。他们是新手、专家还是普通用户?他们了解计算机科学的程度。极客喜欢扩展点，开发人员喜欢示例和脚本，普通人喜欢UI。

原则23：最好的产品是不需要产品手册的。

原则24：

当您无法在两个选项中做出决定时，不要通过提供配置选项将问题直接传递给用户。这只会让用户更加担心。如果连你的专家都无法选择，那么给那些知道的比你少的人礼物合适吗?最好的办法是每次都找到一个可行的选择;第二个最佳实践是自动提供该选项。第三件好事是添加一个配置参数，然后设置一个合理的默认值。

原则25：总是要为配置设置一个合理的默认值。

原则26：设计不良的配置可能会导致一些问题。应该始终为配置提供一些示例值。

原则27：配置值必须是可理解的，并由用户直接填写。例如，您不能让用户填入缓存条目的最大数量，而是应该让用户填入可用于缓存的最大内存。

原则28：

:如果输入了未知配置，则抛出错误。永远不要悄悄地忽视它。悄悄地忽略配置错误常常是几个小时内发现错误的罪魁祸首。

原则29：梦想一种新的编程语言变得简单而直接，但是要真正掌握它通常是困难的。不要轻易改变编程语言。

原则30：复杂的拖拽界面很困难，除非你准备好了10个人的团队，否则不要尝试这种效果。

最后，说说我的一个感受。在理想的世界中，平台应该由多个正交组件组成——每个组件负责一个方面(例如，安全性、消息传递、注册表、mdidation、分析)。似乎是建立了一个完美的系统。但不幸的是，在现实中，很难达到这样的状态。因为当项目处于初始状态时，很多事情都是不确定的，所以您无法实现这种独立性。现在我更喜欢一开始就有适当的重复。当你试图根除它们时，你会发现引入了新的复杂性，分布本身就意味着复杂性。有时候，治愈的过程比疾病本身更糟糕。

作为一个架构师，它应该像一个园丁，更多的是修剪花草，除草而不是定义和建设，你应该策划而不是指挥，你应该修剪而不是定义，应该是讨论而不是标签。虽然在短期内可能感觉不到，但从长远来看，它会给团队带来好处，让他们找到自己的方式。如果你不注意，很容易使架构成为一个空洞的词。例如，设计师会说他的架构是错误的，但他不知道为什么是错误的。避免这种情况的一个好方法是列出一些被广泛接受的原则。这个列表是人们讨论问题的定位点，也是新手架构师学习的路径。