“微”力十足,五大行业微服务架构案例-搜狐

　　【IT168 现场报道】10月29日，SACC系统架构师大会的最后一天。作为中国规模最大的架构师盛会，本次大会共邀请来自互联网、电子商务、金融、电信、政府等20多个领域，150多位技术专家分享了他们的经验。八年坚持，不忘初心，SACC为系统运维、架构师及各种企业IT决策人士提供最具价值的交流平台。

　　近几年的微服务风生水起，SACC大会的最后一天下午，五位来自不同行业的技术大咖分享了各自行业的微服务与服务化架构探索历程，干货满满。这场火花四射，“微”力十足的交流分享很具代表性，开启了现场的讨论高潮。

　　易到用车—PHP高性能服务化框架

　　作为打车行业的代表，易到用车选择自造轮子。简单可控，自成体系，采用标准的URL和JSON数据格式，出于对于高性能的要求和追求等，易道自研PSF系统架构。使用service center服务注册和服务发现，多台service center机器相互独立，client直接和service机器连接通信，基于连接数的负载均衡。其工作机制是client和service通过socket通信，manager进程和worker进程通过pipe通信，manager进程为C进程，而worker进程为PHP进程，用C实现基于pipe通信的处理框架，调用PHP处理函数。

　　自14年发布第一个版本，PSF近几年不断完善，用C实现了PHP RPC应用服务器，C接管了网络连接和网络IO，性能非常强劲，框架层面不存在任何性能瓶颈。同时，改变了PHP运行方式，PHP以后台daemon方式高效运行。简洁高效的协议，采用IP直连的长连接和私有二进制协议。

　　百度外卖——服务化实战探险

　　各类外卖APP层出不穷，从团购到外卖，随着业务规模的不断增大，百度外卖完成了从单一应用向服务化的转变。百度外卖的整体RPC client可以协议打包管理，重点在负载反馈，可以自动检测异常，同时引入探活机制。多次动态重试保证数据一致性，服务之间调用RPC统一化，整体封装到统一框架。非重要服务提供柔性自动容错，通过分布式追踪系统更好地发现服务链调用关系。

　　同时对服务进行分级，最高级别强依赖有分钟级别故障预案，次之依赖可以OP后台操作降级，最次之服务自动容错，优先拒绝次要服务，过滤无效流量，拒绝过载流量。与易到用车类似，百度外卖也有自己的自研部分，在分布式追踪系统上，百度外卖使用自研华佗系统，完成业务与风险控制。

　　上交所——容器技术微服务架构技术实践

　　上交所本着技术体系更加完备，技术过程更加标准，服务发布更加高效的目标，开启了容器技术微服务架构实践之路。上交所基于该目标给出了三个方向：

　　1、微服务以其易开发，易运维，易扩展的特性深受开发者喜爱，但其集成复杂，存在分布式及部署问题。

　　2、Docker容器是轻量级虚拟化的，具有标准化的运行时，易于测试集成，但其运行环境以及使用场景均有限制。

　　3、Devops可以降低风险，快速发布，具有强自动化，但其协作方式和环境氛围略有局限。

　　似乎每个方向都各有优劣，上交所又如何实践呢?上交所在技术体系完备化上建立基于Docker的PaaS平台架构，同时建立微服务架构。在技术过程中，基于Docker的环境管理，建立微服务架构规范，将微服务与Docker结合，基于微服务架构持续集成。在服务高效化上，上交所使软件工程精益化、自动化，同时基于微服务与Docker建立持续交付平台。

　　58到家——分布式服务框架

　　在多服务框架维护成本较高，各类服务繁多，缺乏统一服务治理的背景下，58到家的DSF架构诞生。

　　除了协议之外，DSF序列化是四元组的，包括类型、对象总字节长度、对象属性序号、对象属性值。同时，DSF是跨语言、跨平台的，客户端和服务端使用相同的序列化和协议。同时其高可用，服务可以多节点部署等。在负载均衡上，58也做出了自己的努力，比如静态权重配置和服务节点动态请求超时权重调整。安全问题也不容忽视，IP黑白名单、方法调用授权、服务分组等。此外，在服务治理方面，58在注册中心、流控、调用跟踪系统也做了很多改变。

　　腾讯——微服务架构在腾讯系业务的实践

　　什么是微服务?小服务，功能单一，轻量级的通信机制，独立进程，独立部署，松耦合。腾讯是一家善于思考的公司，在微服务面前更是对价值观和方法论进行了一番分析，对于微服务，腾讯又有哪些见解呢?

　　腾讯认为微服务起码应该具备轻量级服务框架、高可用、持续集成和交付以及运营等能力，以及其中细分的各个特性。不难看出，其他几家企业也在这些方面做出了自己的努力。腾讯从易用性、兼容性、高性能以及多语言的角度考虑轻量级通信框架选型，最终选定了RPC通信、IDL协议、异步架构(EPOLL ET)和多种编程语言结合。腾讯认为消息队列在多层链路调用上的成本可能过高，所以放弃了消息队列。

　　腾讯将很多精力放在了异步调用上，多种异步封装，调用全链路异步。因为单点故障造成延时波动，就可能影响整体调用链故障乃至雪崩。在高可用方面，腾讯名字服务与通信框架透明融合，让用户省心。即便名字服务挂掉，大部分服务依旧可用，因为腾讯在这方面有落地存储。其他各大方面，腾讯都希望可以有一个透明化的效果，尤其是在运营方面，腾讯整个运营过程全WEB实现，通过自动调度提升整体运营效率。腾讯预计年底将整体框架开源，这必会激起广大开发者的摩拳擦掌。

　　总之，不同行业虽有不同的业务需求，但在微服务与服务化架构实践中，不同行业面临的技术难点颇为类似。在开源基础上进行修改的有，自主开发的也有，选择适合自己的方式，有一个可以接受的成本，或许就是最佳的选择。