从1到0思考架构

接手别人的系统是不可避免的问题，这似乎是it界的常态，最初的架构师几乎都会以“系统不需要我了”为理由辞职的。然后他又会接手别人的系统，解决了部分问题后又扔给了别人。 
架构师就像嗜血的动物一样，不同的是，对于他们而言问题才是新鲜的血液。 
没有问题的系统是留不住架构师的，而没有问题去解决的架构师，对老板也是没用的。至少在架构师离开的一小段时间，大家都是这么想的。但是好景不长，(这也是你会接手别人系统的原因)似乎所有的系统都离不开某人。老板都会马上意识到轻易让架构师离职是愚蠢的，至少是轻率的。 
不管怎么样，你来了，然后你首先面对的问题就是先擦屁股或者埋坑。 

从1到0还是1到1.1

大多数我遇到的架构师，都喜欢头痛治头，脚痛医脚，你还别不信。 
比如这样的一个通知类的系统，基于事件驱动的模式，在某个重要的事件如审批、提及发生的时候，通知客户。 

这个设计的问题有两点，一个是可能出现消息丢失，这个丢失系统无法感知；另外一个问题是每次的交互都是系统推送通知给用户(仅是通知不带数据)，而用户收到通知后使用接口从系统获取数据。这样的交互对系统的压力是比较大的。 
我遇到的架构师，多数都想到使用缓存解决问题2，然后通过在发送通知的时候mark一下，get的时候更新mark，如果没有发生这个动作则重发来来解决问题1。 
这是我认为的从1到1.1的解决问题的方式。

那有没有别的方式呢？上述的做法其实可以解决问题的，但是个人觉得思路受限。假设从1到0来思考呢？我们先理解一些模式。

Martin Fowler关于如何理解事件驱动

软件大师曾在博客中有这样的分享 我们相似北美办公室组织了一次峰会，来自世界各地的高级开发人员分享了想法，最大的结果是总结了一些关于事件驱动有用的模式。 
1. 事件驱动 事件通知是最基本也是最简单的模式。当一个系统发生了变更，它会通过发送事件消息的形式通知其它系统。发送消息的系统不要求接手消息的系统返回任何响应，典型的"fire and forget"模式。 
这个模式的好处在于简单和有助于降低系统间的耦合性。不足点则在于太多的事件难以跟踪，发生问题很难调试，且因为事件没有包含所有的数据，客户端需要向源系统发起请求来获取完整的数据。 
我们的上述的例子就是用了这种模式 
2. 事件传递状态转移 其实就是把所有的数据都放到通知里，好处就是减少了向源系统请求这一步，但是缺点是带宽的占用比较大。 
3. 事件溯源 上述的两个模式意在将变更通知其它系统并实现系统间的低耦合，而事件溯源志在保证变更的一致性。事件溯源在系统的状态做出变更时，把每次变更记录为一个事件(日志)，在未来的任何时刻，都可以通过重新处理这些时间来重建系统的状态。 
事件溯源的缺点是如果日志很大，将来重建系统时需要的时间很长。

如何从1到0思考

其实就是从0到1思考，假设这个系统从头开始设计，你会如何设计这个系统？ 
可能你会想到是否可以采用模式2，减少无谓的请求，这样可以大大降低系统的负载。 
另外你确实会想到类似上面的mark方式来保证数据的不丢失，但是基于模式3我们还可以想到：每次的变更可以给它一个版本号，客户端在心跳包中上传这个版本号，服务端比对这个版本，将缺少的数据再次推送给客户端。也可以保持原有的设计不变，同样加上版本号，客户端每次请求的时候带上最后的版本号。 
因为重新站到0的位置思考我们的问题，并且理解了问题的模式，我们可以做出更合适，更简单的方案。相比一味的针对某个点去优化带来的收益更高。之前遇到一个数据库性能的问题，有人提出需要重写大批代码的方案，其实当时的问题是因为读写都针对主库，没有做到读写分离造成的问题。主要针对部分代码适当调整一下就可以达到了目的。而增加缓存的方案，代码量大，而且没能真正地解决问题。