分布式系统原则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） 。好像一个系统构建成这样才是完美的 。但不幸的是，现实中我们很难达到这样的状态 。因为在项目初始状态时，很多事情是不确定的，你无法做到这样的独立性，现在我更倾向于在开始的时候适当的重复是必要的，当你尝试铲除他们的时候，你会发现引入了新的复杂性，分布本身就意味着复杂 。有时候治愈的过程要比疾病本身更加的糟糕 。
（小编点评：不同阶段采用不同的做法，照抄往往会东施效颦）
总结作为一个架构师，应该像园丁一般，更多的是修剪花草，除草而不是去定义和构建，你应该策划而不是指挥，你应该去修剪而不是去定义，应该是讨论而不是贴标签 。虽然在短期内可能会觉得也没什么，但从长远看，指导团队找到自己的方式会带来好处 。如果你稍不留神，就很容易让架构成为一个空洞的词汇 。比如设计者会说他的架构是错误的，但不知道为什么是错误的 。一个避免这种情况的好办法就是有一个原则列表，这个原则列表是被广泛接受的，这个列表是人们讨论问题的锚点，也是新手架构师学习的路径 。
推荐阅读
- 架构师的技术升级之路
- 致敬教师节：当老师不在场的时候 当老师不在的时候作文
- 律师提醒：这4种东西，概不外借！权益受损是小事，严重者要坐牢
- 体育教师的工作总结 小学体育教学工作总结
- 洋学生学品中国红茶学茶艺拜老师
- 康师傅绿茶广告歌曲歌词演唱者欣赏
- 写给亲爱的老师的一封信 给老师的一封信
- 长岛区优秀教师事迹 优秀教师个人材料
- 品茶师和评茶员资质介绍
- 红酒过期了还能喝吗？酿酒师傅给出答案，看完涨知识了