微服务能力层_微服务架构下的高可用和高性能设计

今天再谈下微服务架构下的高可用性设计。

对于高可用性实际应该包括了高可靠性，高性能和高扩展性。因此谈微服务架构的高可用性，首先需要梳理三者之间的关系。

高可用性三个维度和相互关系

对于业务系统的高可用性，实际上包括了高可靠，高性能和高扩展三个方面的内容。而且三方面相互之间还存在相互的依赖和影响关系。

对于三者的关系，我们可以用下图进行描述。

上图可以看到高可靠，高性能和高扩展性三者之间的关系。

对于高可靠性来来说，传统的HA架构，冗余设计都可以满足高可靠性要求，但是并不代表系统具备了高性能和可扩展性能力。反过来说，当系统具备了高扩展性的时候，一般我们在设计扩展性的时候都会考虑到同时兼顾冗余和高可靠，比如我们常说的集群技术。

对于高性能和高扩展性两点来说，高扩展性是高性能的必要条件，但是并不是充分条件。一个业务系统的高性能不是简单的具备扩展能力就可以，而是需要业务系统本身软件架构设计，代码编写各方面都满足高性能设计要求。

对于高可靠和高性能，两者反而表现出来一种相互制约的关系，即在高性能支撑的状态下，往往是对系统的高可靠性形成严峻挑战，也正是这个原因我们会看到类似限流熔断，SLA服务降级等各种措施来控制异常状态下的大并发访问和调用。

数据库的高可用性

在我前面谈微服务架构的时候就谈到，在微服务架构下传统的单体应用要进行拆分，这个拆分不仅仅是应用层组件的拆分，还包括了数据库本身的拆分。

如果一个传统的单体应用规划为10个微服务，则可能会垂直拆分为10个独立的数据库。这实际上减小了每一个数据库本身面对的性能负荷，同时提升了数据库整体的处理能力。

同时在拆分后虽然引入了各种跨库查询，分布式事务等问题，但是实际很多跨库操作，复制的数据处理计算都不在数据库里面完成，数据库更多的是提供单纯的CRUD类操作接口，这本身也是提升数据库性能的一个关键。

如果采用Mysql数据库。

要满足高可靠性，你可以采用Dual-Master双主架构，即两个主节点双活，但是仅一个节点提供数据库接口能力，另外一个节点实时同步数据库日志，作为备节点。当主节点出现故障的时候，备节点自动转变为主节点服务。

简单的双主架构两节点间安装代理&