随着业务的不断发展，传统的应用开发部署模式，在满足业务快速试错的要求下，将会面临开发效率低下、部署运维不规范等诸多问题。而业界微服务的事实标准Spring Boot也在不断流行，因此我们有必要将其与阿里现有的技术栈无缝融合。

在整个融合的过程中，需要保持技术架构一致性，并提升开发体验，因此我们总结了一些经验和教训。本次分享，即为大家带来我们在这些背后的一些思考。

听众受益

• 阿里服务化架构演进；
• Java隔离容器Pandora；
• 微服务框架Pandora Boot；
• 微服务运维与诊断。

51信用卡的技术架构是基于Spring Cloud所打造的微服务体系，随着业务的飞速发展，不断增多的微服务以及指标给监控平台带来了极大的挑战。监控团队在开源vs自研，灵活vs稳定等问题上需要不断做出权衡，以应对飞速发展的需求。本次将会分享我们在微服务下的白盒监控思考，以及如何将时下社区流行的Spring Cloud，K8S，Prometheus等开源技术在企业落地。

听众受益

1. 51信用卡监控平台现状；
2. Prometheus与白盒监控；
3. 微服务下的指标膨胀困境；
4. 基于C*、ES、Druid的混合存储解决之道。

当前，微服务在京东日益深入普及，服务的数量及种类日新月异，开始出现所谓的“微服务大爆炸”，我们在享受微服务带来的好处的同时，又日益开始被迫承受微服务带来的负面效应，这些负面效应大致有如下几方面：

1. 调用端依赖的服务个数及每个服务的实例数越来越多，造成调用端的启动越来越慢；
2. 当前的软负载均衡策略遇到挑战，急需优化、调整；
3. 跨应用、跨系统的调用越来越多，调用关系和依赖关系日益复杂，可观察性越来越差；
4. 各服务的信息比如入参/出参等散落在各个地方，服务调用者无法快速、准确、全面获取这些知识，沟通成本非常高；
5. 跨语言支持日益迫切，基于库方式将开发者绑死在单一技术栈上，与微服务理念相悖；
6. 缺乏灵活、智能的流量控制机制及相应的运维支持手段；
7. 缺乏灵活、适度的安全机制；
8. 特性增加与Bug修复升级非常困难。

基于以上原因，我们决定开发京东新一代的微服务框架及其治理平台，该平台是阿基米德系列产品中的重要一员。幸运地是，我们遇到了服务网格技术，该技术将业务逻辑与通信及服务治理等非业务逻辑进行了彻底解耦，为全面解决上述问题提供了极大的想象空间。当然，如何在京东如此大的体量下运用“服务网格”技术，并且做到与当前的JSF系统兼容及平稳过渡，是一个巨大挑战。

此外，我们将重新定义新一代的微服务治理平台，该平台将引入服务集市的概念，为开发者提供集中、全面、准确的微服务知识体系；通过用户自定义服务属性的机制，进一步把治理平台向业务场景及业务架构拉近，使得业务在系统运维方面更加灵活自由；制定全局的服务身份体系，围绕该体系进行一系列安全控制。

微服务架构下的应用是由一组松耦合的相互协调的服务所组成。这些服务内部通常使用独立的数据库来维护状态，服务与服务之间是通过轻量级的通讯协议进行交互的。如何协调这些服务之间的分布式事务一致性成为微服务架构需要解决的一个重要问题。

本次演讲结合业界普遍采用的Saga技术，以及ServiceComb Saga项目，与大家分享Saga分布式事务最终一致性解决方案以及相关实践经验。

听众受益

了解分布式事务处理的一种新模式Saga了解分布式事务追踪的原理，以及在分布式事务追踪基础上，使用Java实现Saga协调器的实践经验。