微服务架构现在是个热门话题，微服务的高可用性自然也是企业非常关注的。眼下互联网的架构秘籍三板斧“高可用可扩展，缓存提速，消峰减流去并发”，在微服务架构体系中有着不一样的诠释。
在微服务中消息队列不仅用来消峰，还可以通过消息队列来解决微服务之间的多耦合，把同步调用转化为异步调用，减少调用链路，提升系统稳定性。单体应用拆分为独立的多个无形中增加了系统的响应时间，可以通过本地缓存、分布式缓存相结合的方式来弥补性能的损耗。以前通过内部接口调用的方法变成RPC调用多个服务，服务与服务之间还有依赖关系，每个服务接口响应时间也都不一样，简单的设置单个接口的超时时间已解决不了问题，可通过服务定级，哪些服务不能出问题，哪些服务允许有异常，采用降级、熔断的方式来解决问题，以达到系统的高可用。这三种方式如能合理运用，微服务的高可用性大大提升，所以说缓存、队列、熔断降级成了微服务架构中的新三板斧。
以下是相关技术应用中的一些难点解答，供大家参考。
1、微服务架构中有哪些技术手段必须在设计阶段就需要规划进去?
互联网的三板斧：熔断、消息队列、缓存、这个必须有要考虑进入，另外为了提高响应时间，并行化操作也需要提前考虑。
熔断：保障服务高可用的重要手段，用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，则会进行降级处理，用户的请求不会被阻塞，至少可以看到一个执行结果(例如返回友好的提示信息)，而不是无休止的等待或者看到系统崩溃。
消息队列：消息队列(MQ)是一种不同应用程序之间(跨进程)的通信方法，在微服务中引入消息队列的目的就是为了减少链路，减少依赖。
缓存：为了提高QPS，减少数据库压力，分本地和远程缓存;
2、 缓存是每个互联网应用系统必备的组件，在微服务框架下如何用好缓存来提高系统的QPS?
在缓存的使用场景中，有一种2/8法则的说法，即20%的请求访问DB(如有可能再少一点),80%的请求访问缓存。在微服务场景下，本身是接口调用的现在变成了RPC远程调用了，在一定程度上的确提高了单个接口的响应时间。但是从全局角度看，微服务提高了系统的QPS量级，所以从某种程度上来说，因为PRC的原因提高了单个接口的RT是可以忽略的。当然如果是为了最求极致，想尽可能的降低因为PRC带来的接口响应时间，如果是涉及多个服务调用的，可以并行调用服务，同时将并行结果缓存在本地。后端每个原子服务都会对接缓存，这样能有效提高系统的响应时间。
一般API接口发起请求到后端服务，如果涉及到会调用多个接口，那么会有一层聚合层，通常在聚合层做缓存，缓存分本地缓存(如JVM)或者远端缓存(如Redis或Memcache)。由于是都是分布式架构，所以缓存一般采用TTL自动过期来清除缓存。如果业务量非常大，但是对于数据的不一致有比较高的要求，可以设置1秒。如果要求不高可以设置30秒或者分钟级别都可以。但是在软件架构中通常会使用读写分离来提高QPS，由于缓存会导致数据的不一致性，某些场景如需要数据强一致性，可以通过版本号的方式来处理。比如李四读取A数据的时候version=1，同时有用户张三对记录A做了一次操作，那么version=2。这个时候李四是不能对于记录A做变更操作的。
3、 消息队列MQ在微服务中怎么用，有什么好的技巧?使用MQ一定要考虑幂等性吗?
消息队列(MQ)是一种不同应用程序之间(跨进程)的通信方法。消息队列主要有：异步处理 - 增加吞吐量;削峰填谷 - 提高系统稳定性;系统解耦 - 业务边界隔离;数据同步 - 最终一致性保证。在微服务中引入消息队列的目的就是为了减少链路，减少依赖。举例说，用户注册后系统会给用户发积分，发优惠券，以及一些其他初始化操作。如果不用MQ的话，那么需要依赖积分服务，优惠券服务等其他服务。但是对于用户服务来说，只管注册不管其他的衍生服务，所以发送MQ后其他依赖方消费即可。微服务只要配置了重试机制写入接口都需要考虑幂等性。因为需要考虑网络的抖动，数据包会重复提交，如果没有幂等性就会出现脏数据了。使用消息队列也需要使用幂等性，因为消费端可能在某个环节失败后没有commit，导致消息会再次投递的。
4、 使用熔断降级技术需要考虑哪些方面?哪些参数需要调优?
所谓的降级或熔断是针对非核心业务系统，当非核心业务系统因流量过大而出现响应慢，那么部分请求这个接口会出现降级，当达到一定策略之后就会变成熔断。熔断后可以是时候异步做处理。另外一种情况就是手动指定某个接口熔断，例如某电商会在大促的时候把猜你喜欢或者为你推荐给屏蔽。如果没有熔断方式，那么就需要手动写代码，经过开发-测试-预发-线上环节，比较浪费时间。所有的策略都是为了高可用而做铺垫的。一般使用hystrix来做降级熔断功能，可配置的参数非常多，但是重点需要注意的点：circuitBreaker.requestVolumeThreshold circuitBreaker.errorThresholdPercentage execution.isolation.thread.timeoutInMilliseconds hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds 另外，需要支持手动打开熔断器，以防止特殊情况下需要主动打开熔断器。
5、微服务面临压力过大怎么自动进行调整或临时做到弹性增加服务?
流量基本上会分成2种：
1、正常业务流量，运营期间大流量(提前知晓)
2、被攻击流量 大量用户请求峰值基本上都会提前预知，比如运营做活动，会预估用户量，根据这个预估的量来事先做容量扩充。如果是突发性的异常大流量，那就怀疑是否被攻击了，需要做相关网络层面的防护了。一般系统都会基本的保护措施，如， 限流：比如针对IP的限流 黑名单：针对IP的黑名单 通过上述方式基本上能拦截很大的非正常流量，然后系统层面对接口做限流以及降级和熔断来保障平台稳定。
弹性扩容是增加系统能支持的QPS量级。这里涉及到几个需要做无状态的核心组件：
1、缓存：缓存是否支持动态增加;
2、DB：这里的DB是指只读丛库 因为微服务天生支持多实例部署，由于能做到1,2了，那么可以根据营销活动的用户量初步预估下系统在高峰期的QPS会有多少，然后再去计算需要增加多少实例，缓存增加多少只读只读实例，DB增加多少只读实例。
同时需要做好如下3点：
1、控制好限流和熔断策略，以防止流量压垮服务。
2、热门活动场景，本地+远端缓存一起使用;
3、活动期间把一些非核心流程先做熔断处理;
6、微服务主要用什么方法保证高可用呢?硬负载均衡设备还是软负载方式保证?
微服务框架本身就支持了同一个服务发布多个应用实例，且部署的应用和注册中心都有心跳检测，以保障应用都是在线状态。同时框架本身会支持负载均衡以及重试机制，可以确保在单个应用宕机的情况下不影响应用，可以说微服务的框架通过软负载的方式来保证了服务的高可用。
谈到高可用，就想到了微服务，为什么说微服务难，其实并不是难在开发阶段，而且对于整个团队的整体性要求高了。其中包括：运维流程，监控体系。
运维流程：是否有持续集成，是否支持链式部署，支持版本回滚。
监控体系：慢响应，超时、ERROR能否及时的报警通知。
所有要提高微服务的高可用性，不仅仅是研发的事情，而是开发、运维一体才可以。
7、微服务框架部署时的业务连续性如何考虑?
近年金融行业，尤其是银行业监管越来越严格，对业务连续性要求的更高，银行系统对于由传统架构迁移至微服务有较迫切的需求，目前在实际部署系统时，一般需要考虑系统的同城双活或同城、异地多活，以保障业务连续性。那么在迁移至微服务架构的过程中，微服务架构上对于双活、多活的需求是如何考虑的?如何实现异常情况下快速无中断切换、不同中心间数据一致性等问题是否有解决建议?
解答1：
这个问题信息量比较大，同城双活或同城、异地多活甚至目前跨云的多活都是大家所关注的话题。微服务的定义就是服务独立化、动态扩容等一些优点,所以从微服务角度看并不关注多活，双活，只要服务能正常允许即可。但是从架构角度来看，如需要支持多活，双活，那么一些基础设施是否具备了这些特性，比如Redis,Mysql是否支持双主，是否支持主主自动切换，MQ的是否支持。这些工作量非常的大。个人建议在技术能力、人力都不足的情况下不要搞双活，如非得考虑这方案因素，那还是建议去实施主备模式，即每个机房都部署一模一样的系统，当主的出现问题后把流量切到备用上。
解答2：
目前应该还没有微服务跨数据中心的合适技术，跨数据中心，需要解决微服务调度、服务发布的问题，还需要面对时延挑战。所以比较好的方法是一个应用的微服务尽量都尽量在一个数据中心部署，考虑容灾可以在另一个数据中心也部署统一套应用，前端通过负载均衡或者服务治理引流。
解答3：
这个问题其实展开说还是非常复杂的。底层不用区分上层是基于传统的服务方式，还是微服务方式，只需要注意数据同步问题即可。在应用层面，拆分成微服务后，微服务应用数量大量增加，并且会使用到配置中心，注册中心等微服务分布式组件，这些都对网络要求比较高。所以比较好的方式是在一个业务请求在一个机房内完成，同时每个机房部署各自的微服务框架，减少跨机房流量。同时配置相应的微服务监控模块，以及故障自愈。
8、微服务是否一定要Docker容器化?如果是，原因是什么?优缺点都有哪些?
成本角度：docker或者虚拟机将原本单体物理服务器拆分为多台虚拟机，机器之间的资源也是隔离的，所以成本上有很大程度降低。
部署效率：简单说docker和虚拟机都是一个概念，在服务化的场景下docker比虚拟机强的原因其实也很简单，举个例子，明天需要做一个非常大的影响活动，初步估算下每种核心节点服务需要增加10台集群，目前核心服务有12个，即12*10=120台，需要扩容120台机器。虚拟机做法：开通120个虚拟机，配置环境，设置IP，端口，安装应用，启动，调试。按一个熟手没部署一台需要10分钟，那么累计需要1200分钟，约20个小时 docker做法：由于在部署的时候，每个应用都被做成了一个镜像，所以要发布这120个应用，只需要通过脚本或者命令即可，整个过程约1个小时内完成。所以在服务数量不是很多的情况下，用虚机也是能符合要求的。
9、微服务架构下底层数据存储的实现方式?
微服务的底层数据基本上都是异构的，如MySQL、HBase、Redis、ES、hive等等。业务处理都会先直接写入MySQL，然后通过订阅binLog的方式来做数据同步，一般会将binLog的数据写入MQ，消费方在数据处理的时候需要考虑乱序问题。对于要求强一致性的数据一定要携带版号。
10、我们处在微服务+容器的转型探索时期，如何选择微服务框架，以及链路追踪?
框架选择：微服务框架目前比较火的有dubbo和spring cloud，他们各有利弊。spring cloud个全家桶啥都全，但是真正能用好的并不多，无非是组件的堆叠。dubbo也从阿里自己运营转向apache国际化方向，目前互联网大部分公司都是使用dubbo框架，遇到问题也能通过社区快速解决，响应效率比较快，而且有各种技术沙龙可以学习。
链路追踪：APM的选择性比较多，有开源的，有收费的,目前市面的系统基本都是参考Google的Dapper论文来开发的。如果预算充足，可以选择收费的企业版。好处是比较稳定，遇到问题有专人负责解答。如果研发资源充足，又想自己造轮子，可以选择开源版本，如skywalking，Pinpoint,Zipkin,CAT。skywalking,Pinpoint：基本不用修改源码和配置文件，只要在启动命令里指定javaagent参数即可，对于运维人员来讲最为方便;Zipkin：需要对Spring、web.xml之类的配置文件做修改，相对麻烦一些;CAT：需要在程序中硬编码，侵入性比较大。具体选择哪个，这个根据业务团队的熟悉具体产品的程度来决定。
