近万服务实例稳定运行 0 故障，携程微服务架构是如何落地的？

通过接入携程的 Dashboard，可以提供全局的总量、错误量、线程池统计信息，也可以根据机房、协议、序列化格式等聚合数据。还能够自定义告警规则，在问题发生时能够尽早的介入。

4. 动态配置

========

对业务同事来说，有可能会存在依赖的服务突然变慢导致客户端超时的情况。框架人员可能需要在机房故障时，需要全局调整 check 为 false，以解决 A B 服务循环依赖谁都无法启动的问题。动态配置提供了配置热生效的能力，不需要为了一个配置重新发布，成本很高。

服务端的多个方法，可能执行耗时也会有所不同，通过多级别的参数配置，可以设置服务默认超时为 1s，单独为执行较慢的方法设置独立的超时时间为 5s。

服务 Owner 可能更清楚自己服务的耗时，通过服务端对客户端的参数设置，不需要每个调用方都设置一次超时，设置的时间也会更合理一些。为了避免配置出错带来的损失，我们提供了友好的可视化界面。

5. SOA 协议及互通

=============

为了支持现有客户端迁移到 CDubbo，需要考虑支持现有的 SOA 协议。除了要确保兼容 HTTP 1.1 协议不变，其次要保证跟客户端的序列化器一致。

CDubbo 会通过 Tomcat 端口接收 SOA 协议的请求，利用现有的序列化器执行请求对象的转换，并保证 Dubbo 内部调用和 Filter 链路的一致性，确保业务逻辑的统一，也就是业务代码不需要改动，就可以启动两个协议。

![近万服务实例稳定运行 0 故障，携程微服务架构是如何落地的？](https://imgconvert.csdnimg.cn/aHR0cHM6Ly9wN

真题解析、进阶学习笔记、最新讲解视频、实战项目源码、学习路线大纲
详情关注公中号【编程进阶路】

i10dC5ieXRlaW1nLmNvbS9vcmlnaW4vcGdjLWltYWdlLzY2OTJkMWZjMDU2ZDRiMWY4Y2QxODc4MGQ3ZWQ1M2Jj?x-oss-process=image/format,png)

6. 测试平台

========

对于私有的二进制协议来说，没有现成的 Postman 等工具可以使用。有时，开发人员需要在本地验证测试环境的服务，也可能要验证本地启动的服务端，每个开发人员都构造一个客户端显得成本比较高。

通过 VI(github 开源叫 coreStone)，以及利用 Dubbo 2.7.3 提供的元数据中心和泛化调用能力，我们实现了类似 postman 的调用工具。不但可以支持直连，也能够支持本地测试，同时还可以支持 protobuf 序列化格式。关于 protobuf 序列化的测试方案，已经贡献到 dubbo 社区，感兴趣的同学可以自行了解。

7. 升级 Dubbo 2.7.3

==================

关于 Dubbo 2.7.3 的详细升级历程，可以参考：https://www.infoq.cn/article/kOxdaV3y9fMZ0Bzs0jb2

现在回顾下升级的最终结果如何。目前，携程 99% 的服务已经跑在 dubbo 2.7.3 之上，迄今为止 0 故障，只有一些不兼容的小问题，对于不兼容的问题也是确保了编译时提前暴露，运行时没有任何问题。

在发布后，也陆续的出现了一些小的问题，比如预热能力不生效，异常情况下不会回调 onError 等问题，支持服务端异步的 Trace 埋点等，这些问题已经在开源版本彻底修复了。

8. Threadless

==============

业务同事反馈，需要把线程控制在理想的范围之内。但是，dubbo 的线程数量太多，一方面是服务级独享线程池，当调用方依赖了 10 个服务，每个服务的 QPS 为 1，lantency 可能只有 10ms 的情况下，由于每个服务独立线程池，至少也需要 10 个线程了。如果多服务共享一个线程池，由于客户端默认是 Cached 的线程池模式，那么在这个场景下可能只要 1 个线程就足够了。另一方面，对同步服务来说，dubbo 2.7.5 的 threadless 可以省去 DubboClientHandler 线程，Netty IO 线程直接把响应交给业务线程，从而节省了一次线程切换。

通过实践，业务线程数量有了很大程度的下降，在高 QPS 以及依赖服务数量较多的情况下，甚至可以下降 60-70%。

9. CDubbo 服务体系

===============

现有 CDubbo 的服务体系，同时支持 Dubbo 和 SOA 协议，对于 Dubbo 客户端能够支持 TCP 协议的传输，对于现有的 SOA 客户端，能够兼容现有的 SOA 协议。

同时，也能够支持内网和外网 gateway 的请求，保证了多协议的配置统一，以及兼容了 SOA 的序列化格式。

10. 性能表现

=========

从协议层面来看，Dubbo 协议的响应较 SOA 协议有所提升，平均耗时从之前的 1ms 降低到了 0.3ms 左右，当然具体提升也要根据服务的报文及请求量有所差异。

可能有些人会觉得几毫秒的性能提升不足以挂齿，但是性能的稳定性对服务来说会很重要。我们观察了服务流量突增 3-4 倍的情况下，客户端还能保持 0 异常。长连接的多路复用，提供了很好的抗冲击能力。

11. 扩展性

========

微服务框架跟业务代码耦合比较重，框架人员主要是用 20% 的时间解决业务 80% 的需求，另外 20% 的需求却需要 80% 时间的问题，更适合留给业务自己去解决，能够提供这个能力的唯有扩展性，dubbo 无论横向和纵向的扩展能力都很好。

通过实践，发现业务的确在各个层级都有自己的扩展。例如：业务扩展了 Router 层，支持自己的路由规则，扩展了负载均衡策略，机票同时甚至扩展了 Transport 层换成了适合自己的传输协议。

12. 生态

=======

好的生态，可以降低开发成本，例如利用现有的开源 dubbo admin，dubbo go 等组件。另外，也可以降低业务的学习成本，在其他公司学习的 dubbo 框架，到了携程还可以接着用，不需要重新学习私有的服务框架。技术支持也比较少，很多业务同事甚至比我们还熟悉 dubbo 框架。

13. Dubbo 协议现有问题 & Dubbo 3.0 规划

================================

除了前面提到的 Dubbo 框架得到业界广泛认可的优点，在我们实践的过程中，也发现了现有的 Dubbo 2.x 版本协议存在的一些不足，比如在云原生大背景下，协议对网关不够友好，缺乏移动端的轻量级 SDK 等。据我们与 Dubbo 官方维护团队的深度交流，这些点也都是当前 Dubbo 3.0 在重点突破的方向，如下一代协议、应用级服务发现、云原生基础设施支持等，携程作为 Dubbo 深度用户也将持续的参与到 Dubbo 3.0 的建设与落地过程中。

未来(Service Mesh)

================

网上关于 Service Mesh 的意义讲了很多，众说纷纭，个人认为可能最主要还是以下几点。

• 标准化意味着更低的成本，比如研发成本低，学习成本也比较低，其他公司学习的微服务框架，到携程还可以继续用，省去了学习和踩坑的成本；

• 进程解耦，框架同学可能比较感兴趣，中间件无法独立升级的问题一直困扰着框架研发同学，在这个问题上，envoy 可以独立升级也是值得期待的；

• 通过下沉，复用了云基础设施的一些能力，一方面，能够更好的支持多语言，业务根据自己的场景选择合适的语言，另一方面，通过下沉也能够让 SDK 更简单，减少Jar依赖的兼容性问题；

• 因为更加标准以及下沉，能够带来更好的云部署能力，业务出海时可以根据实际情况部署需要的组件，不再依赖框架全家桶了。

1. Service Mesh SDK

====================

下图是 Istio 官网提供的 Service Mesh 架构图，如果说 Istio 解决了控制平面的标准化，envoy 或者 sofa-mosn 解决了数据平面的标准化，那么对于 SDK 来说，是否需要有个标准化的组件，或者是否存在适合我们的标准的 SDK 呢？

对于部分中小公司，没有自己的中间件团队，可能会选择商业版 SDK。但是，对于携程这样的规模，对扩展性要求很强，同时已经存在上千 dubbo 服务的公司来说，我们可能更期待 3.0 的标准协议。

Vue

• 什么是MVVM？

• mvvm和mvc区别？它和其它框架（jquery）的区别是什么？哪些场景适合？

• 组件之间的传值？

• Vue 双向绑定原理

• 描述下 vue 从初始化页面–修改数据–刷新页面 UI 的过程？

• 虚拟 DOM 实现原理

• Vue 中 key 值的作用？

• Vue 的生命周期

• Vue 组件间通信有哪些方式?

• vue 中怎么重置 data?

• 组件中写 name 选项有什么作用？

• Vue 的 nextTick 的原理是什么？

• Vuex 有哪几种属性?