当天再谈下微服务架构下的高可用性设计。
关于高可用性实践应该包含了高牢靠性，高性能和高裁减性。因此谈微服务架构的高可用性，首先须要梳理三者之间的相关。
高可用性三个维度和相互相关
关于业务系统的高可用性，实践上包含了高牢靠，高性能和高裁减三个方面的内容。而且三方面相互之间还存在相互的依赖和影响相关。
关于三者的相关，咱们可以用下图启动形容。
上图可以看到高牢靠，高性能和高裁减性三者之间的相关。
关于高牢靠性来来说，传统的HA架构，冗余设计都可以满足高牢靠性要求，然而并不代表系统具有了高性能和可裁减性才干。反上来说，当系统具有了高裁减性的时刻，普通咱们在设计裁减性的时刻都会思索到同时统筹冗余和高牢靠，比如咱们常说的集群技术。
关于高性能和高裁减性两点来说，高裁减性是高性能的必要条件，然而并不是充沛条件。一个业务系统的高性能不是繁难的具有裁减才干就可以，而是须要业务系统自身软件架构设计，代码编写各方面都满足高性能设计要求。
关于高牢靠和高性能，两者反而体现进去一种相互制约的相关，即在高性能撑持的形态下，往往是对系统的高牢靠性构成严格应战，也正是这个要素咱们会看到相似限流熔断，SLA服务升级等各种措施来控制意外形态下的大并发访问和调用。
数据库的高可用性
在我前面谈微服务架构的时刻就谈到，在微服务架构下传统的单体运行要启动拆分，这个拆分不只仅是运行层组件的拆分，还包含了数据库自身的拆分。
假设一个传统的单体运行布局为10个微服务，则或许会垂直拆分为10个独立的数据库。这实践上减小了每一个数据库自身面对的性能负荷，同时优化了数据库全体的处置才干。
同时在拆分后只管引入了各种跨库查问，散布式事务等疑问，然而实践很多跨库操作，复制的数据处置计算都不在数据库外面成功，数据库更多的是提供单纯的CRUD类操作接口，这自身也是优化数据库性能的一个关键。
假设驳回Mysql数据库。
要满足高牢靠性，你可以驳回Dual-Master双主架构，即两个主节点双活，然而仅一个节点提供数据库接口才干，另外一个节点实时同步数据库日志，作为备节点。当主节点产生缺点的时刻，备节点智能转变为主节点服务。
繁难的双主架构两节点间装置代理，经过Binlog日志复制，下层经过相似Haproxy+Keepalive成功经过的VIP浮动IP提供和心跳监测。
可以看到双主架构更多的是为高牢靠服务。
假设要满足高性能，常驳回的是读写分别集群。即1个主节点承当读写操作，多个从节点承当读操作。从节点依然是经过Binlog日志启动主节点信息同步。当有数据访问恳求进入的时刻，前端Proxy可以智能剖析是CUD类恳求，还是R读恳求，以启动恳求的路由转发。
当咱们启动订单新增操作的时刻，当新增成功的时刻须要极速的刷新订单列表界面，第二次的刷新自身是读操作，然而和前面的写绑定很紧，实践上不太适宜从Slave节点读取数据的。这个时刻可以在启动Sql调用的时刻明白指定能否依然从主节点失掉数据。
当然，大局部时刻或许须要两者联合，既提供足够的高牢靠性，又提供足够的高性能。因此Mysql集群在搭建的时刻既须要启动双主设置，又须要启动多个从节点设置。
在上图这种逻辑部署架构下，基本就可以同时满足高牢靠和高性能两个方面的需求。然而从下面架构部署可以看到，备节点的主和从都处于一种热备无法实践提供才干形态。
能否可以将一切Slave挂到一个Master上?
假设这样设计，那么当主Master产生缺点的时刻，就须要对多个Slave节点启动智能化漂移。这一方面是全体成功比拟复杂，另外就是牢靠性也不如下面这种架构。
对数据库性能裁减的思索
首先来看前面架构自身的一些潜在疑问点：
第一就是CUD操作依然是单节点提供才干。关于读操作占大局部场景的，基本可以经过双主+读写分别集群成功很好的性能裁减。然而假设CUD操作频繁依然或许产生性能疑问。
其次，数据库性能疑问普通分为两个层面，其一就是大并发恳求下的性能，这个可以经过集群负载平衡去处置，其二是单个恳求访问大数据库表含糊查问性能，这个是服务经过负载去处置的。
也就是说下面的设计，在大并发的CUD操作，对大数据表的关联查问或含糊查问操作依然或许产生显著的性能疑问。
如何来处置这个疑问?
繁难来说就是写入经过信息两边件来将同步转异步，启动前端削峰。而关于查问则启动内容缓存或创立二级索引，优化查问效率。
关于查问自身又包含了偏结构化数据查问和处置，相似驳回Redis库或Memcached启动缓存;而关于非结构化数据，相似信息报文，日志等驳回Solr或ElasticSearch构建二级索引并成功全文检索才干。
当面临少量的数据写入操作类操作的时刻，单个Master节点往往性能很难撑持住，这个时刻驳回相似RabbitMQ，RocketMQ，Kafka等信息两边件来启动异步销峰处置就是必要的。这个异步实践上触及到两个层面的异步。
其一是关于发短信，记载日志，启流程等接口服务异步。其二是对长耗时写入操作异步，先反应用户恳求收到，处置完再通知用户拿结果。
而关于查问操作，前面谈到的并发查问可以启动集群负载。
然而关于大数据量表，比如上亿记载的大表含糊查问，这块就肯定启动二级索引。对这种大的数据表的查问即使没有并发查问，假设不启动二级索引，查问效率和照应速度依然很慢。
对半结构化信息启用散布式存储
关于相似日志，接口服务调用日志等半结构化信息，自身数据量很大，假设所有存储在结构化数据库中，那么对存储空间需求很大，而且很难裁减。特意是前面的Mysql集群方案自身还是驳回本地磁盘启动存储的状况下。
因此须要对历史日志启动肃清，同时将历史日志迁徙到散布式存储库，比如Hdfs或Hbase库，然后基于散布式存储再构建二级缓存才干。
构建DaaS数据层启动水平裁减
前面谈到在拆分了微服务后曾经启动了垂直裁减，比如一个资产控制系统可以拆分为资产新增，资产调拨，资产折旧，资产清点等10个微服务模块。
然而在拆分后依然发现资产数据量极大，比如在个人集中化这种大型名目可以看到，一个省的资产数据表就凑近上亿条记载。这种时刻将一切省数据所有集中化在一个数据库控制不事实。因此须要进一步按省份或组织域启动水平拆分。
在水平拆分后，在下层构建DaaS层提供一致对外访问才干。
运行集群裁减
关于运行集群裁减实践比数据库层要繁难，运行两边件层可以很繁难的联合集群控制节点或许独立的负载平衡配件或软件启动集群才干裁减。关于运行集群裁减，自身就是优化整共性能的关键形式。在集群的裁减环节中还是有些疑问须要进一步探讨。
集群做到齐全的有形态化
假设集群做到齐全的有形态化，那么集群就可以做到和负载平衡设备或软件联合来成功负载平衡裁减才干。比如配件罕用的F5或radware等，软件如HAProxy，Nginx等。
Session会话信息如何处置?关于Session自身是有形态的，因此关于Session信息可以思索存储到数据库或Redis缓存库中。
集群节点在启动的时刻往往须要读取一些全局变量或性能文件信息，这些信息假设繁难的存在在本地磁盘往往难以集中化控制。因此干流思绪是启用全局的性能中心来一致控制性能。
假设运行性能成功中存在文件的上行和存储，那么这些文件存储在磁盘本地自身也是有形态的，因此关于这些文件自身也须要经过文件服务才干或散布式对象存储服务才干来成功。
微服务架构下各个微服务间自身存在接口交互和协同，关于接口调用的详细地址信息也须要经过服务注册中心失掉，失掉后可以缓存在本地，然而肯定有变卦后实时升级机制。
四层负载和七层负载
首先看下最繁难的四层负载和七层负载的一个说明:
可以看到关于F5,Array等配件负载平衡设备自身也是支持7层负载平衡的，同时在四层负载平衡的时刻咱们还可以设置能否启动会话坚持等初级特性。要明白四层负载平衡实质是转发，而七层负载实质是内容替换和代理。
也就是说在不须要启动形态保管和基于内容的路由的时刻，咱们齐全可以启用四层负载平衡来失掉更好的性能。
在微服务架构前后端分分开发后。
后端微服务组件可以齐全提供RestAPI接口服务才干，那么自身就有形态。而关于前端微服务组件间接面对最终用户访问，须要坚持Session形态。在这种状况下就可以启动两层负载平衡设计，即前端驳回七层负载，然后端驳回四层负载平衡。
前端缓存
前端缓存重要是分为HTTP缓存和阅读器缓存。其中HTTP缓存是在HTTP恳求传输时用到的缓存，重要在主机代码上设置;而阅读器缓存则重要由前端开发在前端js上启动设置。缓存可以说是性能优化中繁难高效的一种优化形式了。一个低劣的缓存战略可以缩短网页恳求资源的距离，缩小提前，并且由于缓存文件可以重复应用，还可以缩小带宽，降落网络负荷。
详细可以参考：
软件性能疑问剖析和诊断
关于业务系统性能诊断，假设从静态角度咱们可以思索从以下三个方面启动分类
那么一个业务系统运行性能产生疑问了，咱们当然也可以从灵活层面来看实践一个运行恳求从调用开局终究经过了哪些代码和配件基础设备，经过火段方法来定位和查征询题。
比如咱们经常出现的就是一个查问性能假设产生疑问了，首先就是找到这个查问性能对应的SQL语句在后盾查问能否很慢，假设这个SQL自身就慢，那么就要优化优化SQL语句。假设SQL自身快然而查问慢，那就要看下能否是前端性能疑问或许集群疑问等。
软件代码的疑问往往是最不能漠视的一共性能疑问点
关于业务系统性能疑问，咱们经常想到的就是要裁减数据库的配件性能，比如裁减CPU和内存，裁减集群，然而实践上可以看到很多运行的性能疑问并不是配件性能造成的，而是由于软件代码性能惹起的。关于软件代码经常出现的性能疑问我在以往的博客文章外面也谈过到，比拟典型的包含了。
以上都是经常出现的一些软件代码性能疑问点，而这些往往须要经过咱们启动CodeReview或代码评审的形式才干够发现进去。因此假设要做片面的性能优化，关于软件代码的性能疑问排查是肯定的。
其次就是可以经过APM性能监控工具来发现性能疑问。
传统形式下，当产生CPU或内存满负荷的时刻，假设要查找到详细是哪个运行，哪个进程或许详细哪个业务性能，哪个sql语句造成的往往并不是容易的事情。在实践的性能疑问优化中往往也须要做少量的日志剖析和疑问定位，最终才或许找到疑问点。
而经过APM可以很好的处置这个疑问。
比如在咱们最近的名目实施中，联合APM和服务链监控，咱们可以极速的发现终究是哪个服务调用产生了性能疑问，或许极速的定位出哪个SQL语句有验证的性能疑问。这个都可以协助咱们极速的启动性能疑问剖析和诊断。
资源上承载的是运行，运行自身又包含了数据库和运行两边件容器，同时也包含了前端;在运行之上则是对应到详细的业务性能。因此APM一个**就是要将资源-》运行-》性能之间启动整合剖析和衔接。经过APM来发现运行运转中的性能疑问并处置。