微服务高可用架构-基于支付场景的实战
1、麦田理论的由来
早在战国之前，农民们种地实际上是不分区域划分的，一块地上面既种小麦，也种水稻，也种蔬菜，穿插来种，这样不但农作物得不到充分的光照和适宜的营养，同时在后期维护的时候也加大了除草，施肥等成本。
后来有一个农业专家将一块地划分为多个固定区域，每个区域种不同的农作物，在地与地之间划分了地垄用来隔离不同的区域，同时不同农作物也得到了所需的阳光和营养。
这就是麦田理论的由来，在我看来其实微服务与麦田理论有很多相似之处，
2、SOA与微服务
我们在市面上了解到最多的就是soa和微服务的比较，却没有整合DDD在其中，现在我们就拿这三者的关系做一个说明。soa最早经常用在大型传统行业中的企业解决方案，最早包括的套件有webservice、sca、sdo、esb、beml等，它的整体思想是粗粒度，不要求服务单一职责，不要求服务一定是独立布署。从服务治理的角度来说是重ESB，所有服务全部注册到ESB中进行路由和选取以及失败策略，而微服务的思想正好在soa的基础上继承优点，改进不足，强调服务职责单一，细粒度，独立布署，弱管道。
说到DDD，今天我们一说到微服务就会想到DDD，有不少朋友认为DDD就是为微服务而生的，其实不是这样的，我接触DDD最早实际上是用来做UML设计，领域建模的。DDD讲究充血模型，而J2EE模型以传统的分层架构和Spring架构捆绑在一起形成了以贫血模型为主的架构模式，贫血模型的优点是容易入门，分层清晰，而充血模型要求设计者前期对业务理解较深，不然后期项目会产生混乱。另外就是DDD思想比较宽泛，导致形成百家争鸣的姿态，没有形成一套固定的方法论，开发者不容易理解，所以后面关注DDD的人变的少了，而微服务的提出巧妙的借签了DDD里面的限界上下文，子域，领域事件等关键词，在微服务得到越来越多业界认可的情况下，也给DDD带来了重新的焕发。
3、判断项目的好坏
我们说判断一个优秀项目的好坏，从二个方面来讲，优秀的代码和高可用架构，我们在设计高可用架构的同时，也不能忽视代码的重要性，优秀的代码指的是冗错能力，冥等操作，并发情况，死锁情况等，并不一定是指代码写的多漂亮。这就好比盖楼一样，楼房的基础架子搭的很好，但是盖房的工人不够专业，有很多需要注意的地方忽略了，那么在往里面填砖加瓦的时候出了问题，后果就是房子经常漏雨，墙上有裂缝等各种问题出现，虽然不至于楼房塌陷，但楼房也已经变成了危楼。
4、五个维度
梳理完上面的一些问题点后，要考虑如何基于上述问题进行改造，我们的目标是要打造高可用，要从以下五个维度来进行改造。
产品迭代速度：新架构要能够适应更快的产品迭代，要能够使产品快速上线。
系统稳定性：一般至少要达到99.9%的可用性。
研发效率：能够提升研发人员的开发效率，降低学习框架的成本。
问题快速定位：系统出了问题后，能够快速定位问题，使问题能够得到及时响应。
系统耦合度：根据团队和业务情况，将系统做适当的解耦。
5、利用DDD来打造限界上下文，通过这张图我们可以看到，实际上划分了统一接入领域，产品服务领域，业务服务领域，基础服务领域，支撑服务领域，而产品服务领域又包括三个子域：收银台，商户和个人，每个子域又包括多个限界上下文。
6、微服务的服务治理目前主要采用Spring boot+Dubbo的方式，自研探针agent与Zipkin对接进行分布式调用链监控，自己维护Dubbo增加Hystrix，Spring boot starter，Mock Server系统等功能。
7、通道报警切换系统的演进，通过在相应组件或者应用上面增加agent，拦截通道的请求情况通过Collector将通道评分数据汇总给Redis集群，而支付路由系统在进行通道选取的时候会从Redis集群中获取通道的评分以及通道相应的配置项进行综合评定，从而选取合适的通道，另外采集所有的监控数据都会存放到InfluxDB中，通过Granafa进行预警展示，如果通道不可用自动将通道关闭，同时通知研发部门进行问题排查，第一期项目的目标是实现通道半自动切换。
8、双活机房的演进，也是需要二个阶段
第一个阶段是伪双活。
1、二个机房同时提供服务，但需要设置主备机房
备机房的应用只能通过专线访问主机房的数据库
备机房的Redis也需要通过专线访问主机房的Redis
2、当主机房挂了以后，需要先将备机房应用的数据库
配置改成备库，同时备库停机，修改备库为主库
第二个阶段是泳道双活：
双活体系架构的演进，在zk做数据同步的时候，采用二种方式curator的TreeCacheListener监控相应节点的变化从而同步数据，另一个是修改zk源码伪装成observer接收事务日志数据从而实现数据同步。zk同步的其实最好还是不进行同步，泳道隔离，比如像dubbo这种使用的时候，完全可以同步布二套环境，如果使用当当的elastic-job，在做双活的时候就会相对麻烦。
9、集成测试，共有五步，分别是统一编码规范，静态代码检查，单元测试，持续集成，代码评审与重构。
微服务高可用架构
基于支付场景的实战
程超老师直播回看
长按识别下方二维码