感谢海林的帮助，分享的架构知识：
1.2、 服务治理的原则
（1）、N+1保障：
要确保任何你所开发的系统在发生故障时，至少有一个冗余的实例。
（2）、回滚机制：
确保系统可以回滚到以前发布过的任何版本。
（3）、功能禁用：
关闭任何发布的功能
（4）、监控：
在设计阶段就必须要考虑监控，而不是在实施完成之后补充
(5)、多活数据中心：
不要被一个数据中心的解决方法把自己限制住
(6)、只用成熟的技术：
成熟的技术代价低，避免了软件本身的问题造成排查和解决困难。
落地：可演化，有长期价值。前后端不分离的方案，向服务化转化，有明显劣势，而前后端分离方案则有优势。
（7）、异步设计：
一个系统各个模块很可能处理能力，相应能力不同。如果采用同步设计，遇到其中一个环节因为什么原因造成大量的连接超时和读写超时，可能会导致整个系统无法运作。在这个互联网讲究高并发的时代，同步设计难以发挥作用。
（8）、无状态：
无状态设计利于横向扩展和负载均衡，大大提高了可伸缩性。有状态就是有数据存储功能，线程不安全。无状态则天生就是数据安全的。J2EE的session就是有状态的，通常被认为是不好的设计，大部分J2EE中间件在集群时都需要进行session同步
(9)、.小步快跑设计：
小构件，小发布，快试错 就算是在进行重构的时候，永远都不建议把所有代码都调整完成之后在进行测试。
落地:部署一周一次，不要太频繁。
(10)、水平扩展非垂直升级：
必要时把需求分为多个系统，而不是升级原有的系统。微服务是水平扩展的一个例子。不要把所有的功能都集中在一个系统里面。
(11)、设计至少有两个步骤的前瞻性
想的更远一点，减少重构的次数。
(12)、故障隔离设计
实现隔离故障设计，通过断路避免故障传播和交叉影响。
异步设计本身也是遵循故障隔离原则的。异步I/O编程，异步HTTP,异步SOAP，异步SMPP。基于Reactor模型统一调度的长连接和短连接协议栈，无论性能，可靠性还是可维护性，都可以秒杀传统基于BIO开发的应用服务器和各种协议栈。
(13)、自动化
手工操作时效性无法保证，而且“常在河边走，哪有不失鞋。“看起来简单的东西也有可能出错。特别的是针对数据库操作，如果更新时少加了一个条件，可能会对大批数据产生影响。所以，大公司会使用一种DBA平台的内部网站页面来操作线上数据库。这个平台会对查询时间、执行时间，对数据的影响来做判断，如果判断影响大，会要求用户确认，还会根据影响程序做出上级审批，阻止运行等。
-----------------------------------------------------------------------------------------------------------