微服务架构是互联网很热门的话题，某些企业发现系统有性能问题的时候，就把微服务当做一根救命稻草，认为微服务就能解决一切问题，甚至有些企业为了微服务而微服务。那微服务的高可用性自然也是传统企业和互联网都是非常关注的。眼下互联网架构三板斧“高可用可扩展，缓存提速，消峰减流去并发”的架构秘籍在微服务架构体系中却有着不一样的诠释。在微服务中消息对列不仅用来消峰，还可以通过消息队列来解决微服务之间的多耦合，把同步调用转化为异步调用，减少调用链路，提升系统稳定性。单体应用拆分为独立的多个无形中增加了系统的响应时间，可以通过本地缓存，分布式缓存相结合的方式来弥补性能的损耗。以前通过内部接口调用的方法变成RPC调用多个服务，服务与服务之间还有依赖关系，每个服务接口响应时间也都不一样，简单的设置单个接口的超时时间已解决不了问题，可通过服务定级，哪些服务不能出问题，哪些服务允许有异常，采用降级、熔断的方式来解决问题，以达到系统的高可用。这三种方式如能合理运用，微服务的高可用性大大提升，所以说缓存，队列，熔断降级成了微服务架构中的新三板斧。

twt社区特别邀请来自互联网金融的专家：潘志伟，某金融企业，拥有十多年从业经验，精通微服务架构，精通大数据，拥有亿级用户平台架构经验，万级并发的API网关经验。特意帮助大家解决在微服务架构中如何通过“新三板斧”技术保障微服务的高可用性，希望能解决大家在应用微服务担忧。并且进行了原创分享实例：金融行业如何从0开始到4500W用户将单体应用迁移到微服务实践过程分享。

这次我的分享内容主要以金融行业为例，完整讲述了如何将线上运行的单体应用无缝从0开始迁移到微服务的过程，同时也讲述了在微服务实施过程中需要哪些工具的支撑、哪些人的支撑，以及微服务架构下的新三板斧技术等。可以帮助在单体应用是否需要微服务化转型的决策提供非常好的参考思路，同时也可以给正在实施微服务阶段的企业提供全方位的指导，从而帮助大家找到正确的解决问题的思路。

参与提问的样例：

例如：我们目前已经在实施微服务化，RPC框架使用Dubbo 2.5.3版本，主要做生鲜电商类平台。在商品详情页调用了很多服务，比如商品基本信息，优惠券，活动，猜你喜欢等很多服务，当有活动的时候QPS非常高，后端服务压力太大，经常服务宕机，所以打算通过增加缓存的方式来提高QPS，但是需要调用这么多服务不清楚在哪里做缓存，缓存更新需要什么策略，哪些不能缓存？

大家可以参考以上提问的样例，希望能结合自己的实际场景，以及困难来进行提问，这样参与的嘉宾，可以更好详细的针对大家的实际难点进行解答。