前言：
某科技的一个类似电商的系统，部署是使用war包的一个单体系统，使用的是8台服务器作为集群，数据库使用了oracle的双活处理，但是随着日活的增加，需要迁移到微服务架构，目前系统的日活是30万，目标支持日活5000万的微服务架构
基于之前的微服务的应用个例，某个汽车应用领域的APP日活达到了5000万，因此，可以借鉴这个APP来转到微服务架构。系统抽取了基础层作为微服务，比如中间件的使用，如缓存层的使用。
数据从oracle的1500万条记录迁移到PG库，发现数据不一致问题，数据同步机制，目前咨询了京东的架构师，王栋 说道：双写数据库查询支持大并发的查询，保证order库以及下单库的数据库一致。这里提到的使用MQ丢数据，堆积数据的问题，而比如非主线业务可以丢数据，比如论坛，朋友圈等。
讨论推荐架构：微服务+PG库，基于核心业务(保单，支付，人的信息)的数据隔离，服务拆分，论坛，朋友圈，海报等非主线的业务服务化，方便大流量时进行降级处理。
最后达到的理想化的效果，迭代交付，持续交付，数据隔离，服务隔离。
技术细节：DMZ接入层->活动服务 ， 用户服务 ， 订单服务 ->PG库 备份 Orace库。双写数据库oracle以及PG。
会议结束，提到的分布式事务以及非主线业务的先使用微服务开发部署，主线业务还是使用原来的ssm+oracle+Pg。
消费者没有抽奖机会？
这里就补充一个知识点就是SpringEvent以及SpringListener的使用导致消息队列没能获取到实时的数据。
目前生产上提取了一个生产问题就是，用户下单模块，用户下单之后，本来是应该通过SpringEvent的推送可以得到实例化的消息实体，进行推送，而抽奖的模块应该是有SpringListener来监听进行消费，但是，目前通过日志文件查看，消息时间对象创建了，而且也广播了，消费的时间也是在下单入库之后的时间才产生的动作，因此现在解决这个问题使用了治标不治本的兜底方案，就是用户触发询价的时候才查看一次抽奖的机会。
这里引出了一个问题，到底是spring的ApplicationEvent，ApplicationListener的广播没有确认机制导致，还是其他原因。如果后续演进成springboot项目的时候，是否要考虑使用RabbitMQ或者其他有ACK机制的队列来替代。
原来的MVC项目的亮点，可以提取的编码技巧：
原来的MVC 项目按照模块的方式来提供系统的服务支持，系统又8台机器集群来支撑日活30万，注册人员1000万，8台机器共享一个8G的redis内存，目前系统的瓶颈在于，系统会有一些类似秒杀之类的大并发的场景，需要化解性能问题，就在双十一，由于系统是单体架构，整体部署成一个war包，系统的人员注册模块hang了，整个系统都hang，整整停止服务10分钟。
系统的模块方面，从模块分包来看，特殊节日的模块，比如，世界杯活动，国庆节活动等，单独出一个模块来支持，过了活动就会停止相应的模块部署。而且在后台，核心的代理商管理界面，由于有活动的维度管理，比如类似于一些条件文件的处理，这里的条件都封装为一个数据库的json格式的字段，只要代理商勾选了，就会进行入库的处理，当活动界面需要校验用户的活动资格的时候，就会读取json的维度限制，这样的处理就避免了数据库还需要设计一张维度表来维护。 如果后续对数据要求一致性，这里看到一篇文章关于redis实现的分布式锁，后续可以参数这种思想来参考，这里还附上了redis分布式锁里面使用到的CountDownLatch的详细说明以及zk实现的分布式锁的核心是子节点排序，每个节点都监听一个zxid比自己小一点的节点来顺序执行业务的详细说明
