架构评审

今天写一个架构评审意见，需要一个基本逻辑做支持，我写在这里。

架构设计以简单为美。这背后的逻辑有点像所谓的“为道日损”：你做一件复杂的、长远的事情，中间有很多“意外”，任何一个意外补充进来，就可能和你依赖的逻辑冲突，你初期的概念越复杂，后面处理这个意外的余地就越小，你就无法响应这个意外，那这个事情可能就做不成了。

这好比你去一个地方，一条路比较远，但每五分钟一辆大巴，前后步行不到3分钟，肯定能到，这个事情如果比较重要，我就会选择这条路。另一个选择比较近，但要求8点前一定到渡头，8个小时才有一班船，到了对岸要赶上一班Bus，2个小时有一班。然后还要在下午5点前过关，否则要等第二天，这条路虽然快，但它的条件多，任何一环只要你有意外，这个事情就失败了。所以君子取其厚，不取其薄，虚心实腹，做大的事情就要选择简单的，意外少的路径。

软件设计一样的，大部分时候，我们没有正儿八经把代码写出来跑一跑，你都不敢肯定你的设计肯定能正常使用，就算这类应用你试过很多遍，它还会有别的变数：比如用户变需求？比如用到场景上发现最初理解的的需求不对？——成功需要千百个理由，失败只需要一个理由。你高考考上清华，需要十年如一日的苦读，但你要失败，只要高考那天得了急性肠胃炎就可以了。所以，我们分析需求的时候，可以一路推演下去，把每个模块怎么弄的细节都分析清楚（当然，这个还受时间的限制），但等我们开始动手写代码的时候（特别是写设计的时候），你得把所有非关键系统统统给我抛弃掉，认为你“不知”，你要用最小的依赖实现你的功能。

比如你有一个短信服务，经常报错，错多了你尽量希望不要用它，然后系统自动选择另一个，选择的时候除了考虑它错得多不多，还要考虑它别的方面是否比别人好，比如它的时延是否比较小……你分析的时候会有很多细节。但你编码的时候不能直接把这些细节直接不分大小地写到逻辑中，否则你后面加逻辑就没法加了，随便怎么加都会碰到别的逻辑链。

你让我看，这个逻辑很简单：我有一些短信运营商的sms服务，这些服务有一组参数表示它被选择的优势，这属于服务的属性。我选择可靠的服务根据这些参数，用特定的算法来选就好了。这是选的过程。然后如果我使用的过程中它出了错，我要复位它，怎么复位这种烂事，也和我无关，反正就是错了，错了我就放弃它，然后我重新选择一个，而“选择”这个问题，就又回到前面那个算法上了。

这样，在架构的“大逻辑”上，我们只看到“服务属性，服务选择算法，出错重选”这三个逻辑，至于出错处理，我们只要考虑服务属性和选择算法怎么更新就可以了。而用户，更加什么都不用知道。这就是常说的架构就是关注点分离。

我们当然应该分析细节，但分析完了，你必须对细节进行分解分配，校验你的“架构逻辑”是否还能处理这个意外，而不是不分层次地把细节暴露到高层逻辑中。如果你总这样处理新需要，这个软件架构就无法持续维护下去了。