97条架构建议之隐喻-维护-舍得

97条架构建议之隐喻-维护-舍得

不要滥用架构隐喻

架构师喜欢使用隐喻。对那些比较抽象，复杂和变化移动的目标，隐喻提供了很好的具体媒体。

很容易让人沉迷，滥用隐喻。

可能出现的问题

隐喻可能导致乐观的解读系统，导致系统缺少任何约束
可能缺少对实际业务关注

关注应用程序的支持和维护

应用程序的支持和维护永远都不应该是时候才考虑的事情，应用程序80%的生命周期
都是在维护上，设计时应该多多关注支持和维护的问题。

我们应该做到：

理解开发人员和支持人员确实具有不同的技能
在项目中尽早地引入支持负责人
将支持负责人作为团队的核心成员之一
让支持负责人参与规划应用程序测支持

有舍才有得

有时，接受某种约束或者放弃某个特性，可带来更好的架构，这种架构在构建和运维上
都会更加简单，而且成本更低。

一个著名的猜想就是：cap定理，一致性，可用性，分区容错。

分布式系统中通常期望这3个特性，试图同时拥有三者，将大幅度增加工程费用，
显著提高复杂度，也无法真正获得预期效果和实现业务目标。

如果数据必须是可用和分散的，强一致性会不断的增加成本，最终将无法达成目标

如果系统必须是分布和一致的，确保一致性将会导致延迟和性能问题，因为系统的各个部分未同步之前无法提供服务，它最终是无法使用的。

我们要谈架构上的偏移，而不是原则层面上的设计。
我们必须思考:

我们为什么需要这些特性？
这样可以获得什么好处？
何时才能期望这些特性？
如何才能打破系统成规以达成更佳的效果？
永远不要放弃质疑

我们应当珍惜这种权衡，往往能产生富有创造性和创新性的结果