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