最近在做系统升级，由于当时设计的局限，导致系统不停服，保证服务的做法非常麻烦。当时再定方案的时候，由于自己在这方面没有经验，导致有些乐观。到了实际做的时候，预期时间至少比预想的多了一周的时间，要知道，在互联网公司，一周的时间是个非常长的时间。而这一周，还包括了OT。
在这里总结一下分布式系统设计的大忌，本来想试着分一下级，但是还是算了，一来标准太多，无法制定一个合适的规则来界定;二来自己的经验也在增长，低调一下是自己也没详细的研究过超过5个分布式系统;三来做事情还是要严谨，不做没有十足把握的事情。
1. 忽视服务接口的设计
虽然大家口口声声说对于一个集群来说，每台机器都可能出故障。但是做方案设计的时候，某些资源却向用户直接暴漏了服务的实际地址。对于一个服务几年的服务器来说，故障的可能性非常大，尤其是如果这个服务器的平时负载比较高的话。我不清楚一台服务器的平均保修时间是多少，但是绝对不可能是几个小时能搞定的，这个时间少则一天，多则半个月甚至更长。对于一些高级的用户，它会使用本地的cache，或者其他的策略来屏蔽调用服务不可用带来的影响，但是，几天的停服对于用户方的影响是无论如何不可能忽略的。
这种问题发现后，可能简单的发布一个新版本的api，或者一个简单的配置文件就可以纠正。但是对于线上用户来说，他们运行的是一个一直都在running状态的服务。这个简单的改正可能需要他们服务重启，这对于一个大型的集群来说，带来的成本非常高。如果是因为这个服务的不可用导致了线上事故，那么应用方肯定会非常主动的去修正这个错误。但是如果使用架构方发现了这个问题，而主动推动应用方去修改，可能应用方会因为各种原因而推脱。
因此，设计服务的接口一定要注意，这个接口一定要是稳定的，而且后台服务的故障，升级等操作绝对对于用户要是透明的。不要将服务的实际地址暴漏给用户方:这台服务器终有一天会挂掉。尤其是对于C++等需要编译的api来说，这个接口就更加重要了。毕竟api的修改对于应用方来说意味着要重新编译;重新编译意味着要重新走一下发布流程：至少要提测吧。
2. 后台升级对用户不透明
这实际上是又是一句大家都知道的。但是设计时确实有时候会忽略。对于弹性计算系统来说，服务的伸缩是必须的，这个也是设计的目标之一。但是对于一些小规模的计算集群来说，可能大家认为伸缩不是最重要的feature。最重要的feature就是能够快速的完成系统设计和实现，为用户服务。但是实际上，这个通过一些简单的修改，就可以完成：Worker上带一个agent和master或者meta server通信，保持心跳。心跳超时的Worker会被下线，以后的服务都不会发送到这个Worker上来。而新加入的Worker则会加入集群接收计算任务。这个不单是应对服务的伸缩，也是为了应对机器的故障。因此不用太大的改动，就可以将一个系统从山寨提升到真正的可用。
一个系统的服务质量，不是说在一般情况下的服务是可靠的，除了网络丢包、网络传输造成的问题外，服务质量可以做到10000个请求至多有1个失败就是说这个系统是可用的。评价服务质量的另外一个重要指标是全年可服务时间。这个要将机器故障，机房故障考虑在内。如果依赖于运行环境没有问题，才能达到99.99，那么这个服务就有点山寨，对于重要的应用方来说，这种服务不可接受。
3. 应用方设计时未衡量后台服务失败的影响
如果服务的可靠性要求非常高，比如是直接面向互联网用户的，要求任何时间都能够对互联网用户提供服务，那么就需要在调用服务时做下服务不可用的预案。甚至做下超时机制：如果服务调用指定时间不返回，那么需要有其余的逻辑来替代。
当然了本次还遇到很多其他的痛点，每个都是设计上得小瑕疵，当时注意的话不会增加工作量，或者增加很少的工作量就可以做到可用。互联网强调快，那么底线应该是可用吧。易用可能是更要的要求。当然了这个可能可以一种互联网风格，就是一个事情可以快速做完，快速上线。当时上线时候也做了二期需要做的改进，但是后台发现上线效果好，符合预期。又去做其它高优先级的事情去了。导致原来设计的局限就永远的停留在那里了，这就是为后来人埋下一个坑。。
本次升级的时候，由于信息的不一致导致一台服务器停服，导致大面积的失败。后来为了避免其它的集群出现类似的问题，因此所有的信息都重新确认了一遍。而这带来了半天的枯燥工作。因此，自己做设计的时候，一定要注意，不求***，但求可用，在机器故障，服务升级，对于用户来说，服务都可用。
BTW，正在做一个架构的设计，细节是魔鬼，正在和魔鬼做斗争。
