拆解交易系统--服务高可用

系统稳定性和系统可用性是对在线系统很重要的两个评价指标，也是最重要的系统能力，系统可用性或者成熟度不足，将会造成重大的事故或者经济损失。

系统故障在研发团队一般的生命周期如下：

原则按照事前事中事后来分析的话，如下：

事前：进行故障预案设立，进行主动防御，降低故障发生概率
事中：及时感知故障，并快速定义和定位故障
事中：可以快速响应，及时止损
事后：故障快速处理，快速恢复
事后：故障复盘，吸取教训，制定规范

稳定性保障体系如下：

为开发一套稳定性的应用系统，需要遵循一些设计原则，也有一些手段可以作为抓手。

比如系统简单更好理解，结构也更为清晰，可以做一些扩展性的设计，遵循KISS原则。现实中常见的一些问题是过渡设计，过于炫技，制约了系统的快速迭代能力和快速扩展能力，好的架构师是懂得在多角度做取舍，而不是只有技术的一个角度。

前面文章讲过，将大一体系统拆分为多组件的微服务之后，可以清晰的看到系统边界，更好的面向领域进行设计，也降低了系统复杂度，模块自身也可以更好的自治，符合了软件设计思想的单一职能的原则，但这里也存在拆的过粗或者过细的风险，这种职能依照架构师的天分而来了，粗细都各有理由。但是我个人还是推崇DDD的限界上下文方式进行拆分的，在结合业务复杂度和团队规模进行判断。

做好系统隔离，可以有效防止风险的扩张和传递，之前的文章中介绍了系统隔离和机房隔离。所以可以发现隔离在不同层次上都可以实施，比如系统级别的，数据库级别的，连接池级别的，线程池级别的。隔离原则遵循，主要，次要，核心，非核心等原则就好。

为了避免单点，就需要做好冗余，和多副本。这样也带来了资源和成本问题。之后的资源利用率也是个问题。冗余可以体现在无状态服务层面上，硬件层面上，机房层面上，这些都不能单点部署。所以冗余是高可用很重要的手段。

服务需要做到无状态，有状态会造成什么问题呢？数据一致性，并发控制，数据可靠，服务可靠，幂等性，重试，分布式锁都是有状态服务可能面对到的问题，所以做好无状态服务，你后期的系统技术债会小很多。

异步调用是系统提升性能的很有效手段，大部分场景都可以考虑异步处理，之前在我们周会上还进行过激烈的讨论，大致意思是系统设计或者业务设计上究竟有没有强一致性场景，如果没有是否全部可以做到异步呢？异步处理可以带来性能和弹性两方面的收益。

系统架构的迭代方式根源有很多种，比如业务驱动，技术驱动，甚至有BUG驱动。

我认为一个好的架构师应该是具有悲观主义思想的，时刻想着系统面向失败和故障是如何反应。

他们的思想一般是被莫非定律缠绕着。不心存侥幸是他们的做事法则。