1.2 服务治理和架构
我在硅谷那段时间，每天早上都单独要一份omelet，就是美式煎蛋。2个鸡蛋和黄油是必选的，另外需要自己在需要放的材料上打钩，有多种芝士可选，另外还可以勾选洋葱，蘑菇，培根，西兰花等。
回国之后，经常也会自己这样做早餐，只是总会在摆盘时，用圆火腿斜切两片，然后将这这个片再四六分的切一刀，大的两个半片拼起来拼成一个心形摆到盘子的一边。在高脚杯中倒入热牛奶。这就是简单而精致一天的开始。
做omelet的原则是——鸡蛋和黄油必选，其他可选。架构也有自己的设计原则。这些原则中很多都是在架构一开始的设计中就要考虑进去的，这样在出现任何问题时，我们都能够及时的处理，和把问题影响范围缩到最小。
总的来说，有以下原则。
1.N+1设计
要确保任何你所开发的系统在发生故障时，至少有一个冗余的实例。
一般初创的项目，考虑到刚开始没有什么量，都是以最小单元上线。平常所说的最小单元就是一主一备两个服务，来保证高可用。
2.回滚设计
确保系统可以回滚到以前发布过的任何版本。
现在大家都在使用一些持续集成和自动化部署工具，上面大家会感觉理所当然的看到回滚按钮，点击进入可以选择回滚到上次版本或者回滚到某一个特定版本。
实现原理也很简单：最近的几个版本，在新版发布时旧版本会被重命名，命名时后缀上时间等版本信息。点击回滚时直接将被重命名的版本改回来即可。但是将所有历史版本都保留会很占用资源。所以较旧的版本还是会从SVN、GIT等版本控制管理工具上重新编译发布。
3.禁用设计
关闭任何发布的功能。
当一个功能出现严重问题不得不关闭时，如果关闭整个系统代价就有点大了。所以要有单个功能的开关。比如在交易系统中，可能会遇到某些银行或者其他支付渠道故障，需要暂时关闭某些支付渠道。如果遇到链路积压，则需要关闭整个支付功能，让用户采用现金或者其他支付手段。这样的代价要比多次发起退款和支付，用户和商家都无法分辨是否实际支付成功代价要小很多。
4.监控设计
在设计阶段就必须要考虑监控，而不是在实施完成之后补充。
因为设计阶段设计人员需要比较清醒，自己想要达到什么效果，关心的指标是什么。将监控放到设计阶段，开发阶段就可以做合理的埋点。这要比实施完成后再加监控对系统的影响要小，代价要低。
5.设计多活数据中心
不要被一个数据中心的解决方法把自己限制住。
随着企业数据和IT资源不断集中，风险也相应集中，为减少或消除停机对业务可用性造成的影响。金融企业一般会按照“两地三中心”的模式建设数据中心。所以跨机房之间的通信成了企业不得不解决的问题。这个在后面的文章中会相信讲到。
6.只用成熟的技术
成熟的技术代价低，避免了软件本身的问题造成排查和解决困难。
笔者之前有次面试失利，自觉技术不错，心里想不明白，所以找来朋友帮我分析。朋友看了我的简历，给出中肯的评语：“码农思维”。里面写到自己正在自己研发一个搜索引擎框架。朋友就说：“现有框架不能满足需求吗？你这种思维，大家跟着你干会很累，还不出业绩。”
成熟的技术通常开发成本低，开发效率高，可扩展能力强，文档丰富，还有很多社区，人员变动的替换成本较低，是业务部分的优先选择。
7.异步设计
一个系统各个模块很可能处理能力，相应能力不同。如果采用同步设计，遇到其中一个环节因为什么原因造成大量的连接超时和读写超时，可能会导致整个系统无法运作。在这个互联网讲究高并发的时代，同步设计难以发挥作用。
8.无状态设计
无状态设计利于横向扩展和负载均衡，大大提高了可伸缩性。
有状态就是有数据存储功能，线程不安全。无状态则天生就是数据安全的。J2EE的session就是有状态的，通常被认为是不好的设计，大部分J2EE中间件在集群时都需要进行session同步。
9.小步快跑设计
小构件，小发布，快试错 就算是在进行重构的时候，永远都不建议把所有代码都调整完成之后在进行测试。小步快跑的研发方式不是敏捷开发的专利，而是适用于各类软件开发应用中的一个基础准则。小步快跑的设计思想体现了简单，快速反馈的特点。
10.水平扩展非垂直升级
必要时把需求分为多个系统，而不是升级原有的系统。
在垂直扩展模型中，想要增加系统负荷就意味着要在系统现有的部件上下工夫，即听过提高系统部件的能力来实现。而水平扩展模型中，我们不是通过增加单个系统成员的负荷而是简单的通过增加更多的系统成员来实现。微服务是水平扩展的一个例子。不要把所有的功能都集中在一个系统里面。
11.设计至少有两个步骤的前瞻性
想的更远一点，减少重构的次数。
重构代码是危险的，代码的变化会导致测试的压力很大。除非有必要的理由，否则不要轻易重构。
12.故障隔离设计
实现隔离故障设计，通过断路避免故障传播和交叉影响。
异步设计本身也是遵循故障隔离原则的。异步I/O编程，异步HTTP,异步SOAP，异步SMPP。基于Reactor模型统一调度的长连接和短连接协议栈，无论性能，可靠性还是可维护性，都可以秒杀传统基于BIO开发的应用服务器和各种协议栈。
13.自动化
手工操作时效性无法保证，而且“常在河边走，哪有不失鞋。“看起来简单的东西也有可能出错。
忙中出错是经常会发生的事情。特别的是针对数据库操作，如果更新时少加了一个条件，可能会对大批数据产生影响。所以，大公司会使用一种DBA平台的内部网站页面来操作线上数据库。这个平台会对查询时间、执行时间，对数据的影响来做判断，如果判断影响大，会要求用户确认，还会根据影响程序做出上级审批，阻止运行等。
架构设计的这些原则建议读者也像笔者这样在纸上画一下，做一个梳理。
架构设计很多需要考虑的问题可以通过服务治理来解决和简化。所以服务治理也是在架构设计开始就需要考虑的问题。
