微服务：闭门造车，不如看看大厂怎么做的 | Q推荐

近年来，各企业都在加速向信息化发展，计算和存储等资源也逐渐向虚拟化过渡。随着公司业务的发展和新技术的不断引进，系统规模变大，数量变多，在技术架构的统一性和标准性上的差距也逐渐显现。为解决以上问题，以服务化的理念构建应用系统逐渐被企业所采用。

微服务框架则是服务化理念构建应用系统的落地方式，由于微服务架构中组件彼此可以独立地进行缩放，所以对每个组件的开发和维护都相对容易，是应对当前及今后快速变化的业务需求比较好的选择。

但微服务落地是一个复杂问题，涉及到 IT 架构、应用架构、组织架构等多个方面，这是一个循序渐进的阶段性过程，而在每一个阶段都会遇到运维、部署、安全等问题，包括组织协作上的问题。本文推荐几个即将在 QCon+ 案例研习社上线的大厂实战案例，一起了解下他们在微服务治理和架构演进过程中遇到的难题和解决方案：

1 OPPO 面向云原生的下一代微服务框架设计与实现

OPPO 互联网业务用户数已经高达 2.5 亿，日常 QPS 在数百万级别。目前常见的 Dubbo 等微服务框架客户端集成了服务发现、服务治理、负载均衡等逻辑，非常重，伴随的问题包括：升级困难、多语言支持较弱，与 Service Mesh 的思想格格不入。

因此 OPPO 面向云原生设计了下一代高性能微服务框架，客户端非常轻量级，服务治理、服务发现等功能全部在代理层实现。底层采用类似 QUIC 基于 UDP 的可靠传输协议、DTLS 的传输加密协议、HMAC 消息可靠性验证机制，支持 Unix Domain Socket，绕过 Linux TCP/IP 协议栈高性能拦截器请求；其中 Web 服务框架 ESA Restlight 兼容 Spring cloud web 以及 JAX-RS 规范，底层采用 Netty 实现，全面支持 Java 原生协程以及全异步编程，QPS 相比 Spring Cloud/RestEasy 提升 3 倍以上，并发处理能力提升 5 倍以上。

演讲提纲

1. 为什么要研发下一代的微服务框架

2. ESA RPC 基于 UDP 高性能传输协议实现

3. Java 协程在 ESA Restlight 框架实践经验

4. Service Mesh 如何超越原生直连性能

2 微保 Service Mesh 研发实践中的取舍

微保成立之时，后端系统采用微服务系统架构。作为一家互联网保险创业公司，公司业务快速发展，业务快速迭代要求越来越高。自从 2017 年 11 月第一款产品微医保上线至今 2 年多时间，公司目前微服务数量已达八百多。随着微服务数量的膨胀，原来基于框架模式构建的微服务系统逐渐暴露出各种问题，比如多套语言框架维护成本高；业务和基础框架强耦合导致微服务治理新特性开发、推广举步维艰等等。

为了解决上述一系列问题，公司综合自身的情况和业界技术的发展，基于 Service Mesh 技术自研了新一代微服务系统架构。目前公司超过 1/3 的微服务已经接入自研的 Service Mesh 技术，而且自从 2019 年 5 月首个服务接入至今，基于新技术的服务运行正常，没有发生过生产事故。

演讲提纲

1. 微保第一代微服务架构

2. 微保第二代微服务架构

3. 微保 Service Mesh 研发

4. 规划和展望

除此之外，唯品会基础架构团队核心成员郑德惠也会带来唯品会《从服务化到 FaaS 的探索之路》以及字节跳动基础架构部工程师童飞帆分享的《字节跳动混沌工程的落地实践》，如果你还想了解更多其他技术领域的大厂前沿实战案例，QCon+ 案例研习社等你来！覆盖 12 大技术领域，贯穿 40 个热门专题，众多技术专家联合带来 200+ 大厂前沿技术落地案例，365 天畅学不重样！

目前 QCon+ 案例研习社特惠预售，送来 8 月惊喜福利，畅学一年仅需 3749 元！（原价：4999 元 / 年）活动截止 8 月 31 日，快来扫码参与吧！了解更多活动内容也可点击【阅读原文】