几种微服务框架调研报告

,以拆分和服务化为基础，将海量用户产生的大规模的访问流量进行分解，采用分而治之的方法，达成用户需要的功能指标，并同时满足用户对高可用、高性能、可伸缩、可扩展和安全性的非功能质量的要求。,业务的功能划分：每个单一的业务功能叫做一个服务，每个服务对应一个独立的职能团队。,去中心化治理：微服务倡导去中心化的治理，不推荐每个微服务都使用相同的标准和技术来开发和使用服务。,交互模式：在微服务领域，微服务之间的交互通过定义良好的接口来实现，不允许使用共享数据来实现。通常使用RESTful样式的API或者透明的RPC调用。,组合依赖：根据业务流程处理的需要，以一定的顺序调用依赖的多个微服务，对依赖的微服务返回的数据进行组合、加工和转换，最后以一定的形式返回给使用方。,容错模式：, 熔断,当服务的输入负载迅速增加时，如果没有有效的措施对负载进行熔断，则会使服务迅速被压垮，服务被压垮会导致依赖的服务都被压垮，出现雪崩效应，因此，可通过模拟家庭的电路保险开关，在微服务架构中实现熔断。,限流,针对服务突然上量，我们必须有限流机制，限流机制一般会控制访问的并发量，例如每秒允许处理的并发数及查询量、请求量等，实现方式如计数器，令牌桶等。,拆分粒度：,按照微服务的初衷，服务要按照业务的功能进行拆分，知道每个服务的功能和职责单一，甚至不可再拆分为止，以至于每个服务都能独立部署，扩容和缩荣方便，能够有效地提高利用率。拆的越细，服务的耦合度越小，内聚性越好，越适合敏捷发布和上线。,优点,缺点,下文将介绍下几种微服务架构的情况。,二、Spring Cloud,,,模块交互流程图,,1️⃣ Spring Cloud利用SpringBoot的开发便利性巧妙的简化了分布式系统基础设施的开发，组件支持丰富，功能齐全，为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等。它们都可以用SpringBoot的开发风格做到一键启动和部署；,2️⃣ 使用 HTTP 协议的 REST API，服务提供方和服务消费方通过 Json 数据格式交互，只需要定义好相关 Json 字段即可，消费方和提供方无接口依赖。通过注解方式来实现服务配置，对于程序有一定入侵；,3️⃣ 性能上因为是HTTP短连接，系统并发量和响应时间不及RPC长连接方式（如Dubbo，相差三倍左右），在报文比较小，响应时间要求严格的场景不太适合；,4️⃣使用spring boot admin作为服务基本情况监控，原理是Spring Boot Actuator组件；,5️⃣ 部分组件的功能及稳定性并未达到生产级别，使用者不多，需要引入其他功能相似组件。,三、Dubbo,Dubbo是一个分布式、高性能、透明化的RPC服务框架，提供服务自动注册、自动发现等高效及多样性服务治理方案，可以和Spring框架无缝集成。,,,Dubbo分层结构设计图,对外配置接口，以ServiceConfig, ReferenceConfig为中心，可以直接初始化配置类，也可以通过spring解析配置生成配置类；,封装了所有接口的透明化代理，而在其它层都以Invoker为中心，只有到了暴露给用户使用时，才用Proxy将Invoker转成接口，或将接口实现转成Invoker，也就是去掉Proxy层RPC是可以Run的，只是不那么透明，不那么像调本地服务一样调远程服务；,封装服务地址的注册与发现，以服务URL为中心，扩展接口为 RegistryFactory, Registry, RegistryService；,封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为 Cluster, Directory, Router, LoadBalance；,RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为 MonitorFactory, Monitor, MonitorService；,封装RPC调用，以Invocation, Result 为中心，扩展接口为Protocol, Invoker, Exporter，Protocol是核心层，也就是只要有Protocol + Invoker + Exporter就可以完成非透明的RPC调用，然后在Invoker的流程中实现Filter拦截点；,封装请求响应模式，同步转异步，以Request, Response为中心，扩展接口为Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer；,抽象mina和netty为统一接口，以Message为中心，扩展接口为Channel, Transporter, Client, Server, Codec；,可复用的一些工具，扩展接口为Serialization, ObjectInput, ObjectOutput, ThreadPool。,,,Spring Cloud与Dubbo功能对比,,,四、Spring Cloud Alibaba,类似Spring cloud的架构，适配集成Alibaba的多种中间件，注册中心换成了Nacos，限流熔断从Hystrix换成了Sentinel，服务间调用可以使用Dubbo，使用RocketMQ作为消息总线及事件驱动组件，用Seata组件（前身是fescar）支持分布式事务功能，目前最新版本是2.1.0.RELEASE。,,,,Nacos基本架构,,Sentinel 的主要特性,,Sentinel 的开源生态,,与spring cloud相关组件对比,,几种服务治理组件对比,使用demo：https://www.jianshu.com/p/9a8d94c0c90c。,五、Service mes,如下是简化的Service Mesh架构，服务A和服务B相互调用，不再是以前通过微服务框架直接指向的方式，而是在中间加了两个叫做Sidecar（边车）的东西，各种服务都在这里处理数据上的逻辑。Sidecar的作用是数据面的代理，贴近数据并受控于控制面。,,基本架构图,实际业务中，尤其是中台架构下，企业往往需要很多的微服务，即服务A、服务B相互调用情形不断扩展，逐渐形成更多的服务加Sidecar的组合，就变成了一个真正意义的Service Mesh。,,服务的网格化（mesh）,,Istio架构图,主流云原生Service Mesh框架是Istio，Go语言实现，与容器编排系统Kubernetes一脉相承，下面介绍其主要组件，目前Istio版本为1.3.x release：,,1、Service Mesh所带来的核心价值可以总结为：,2、数据面以Envoy Proxy作为代理组件。通过Outbound流量拦截或显示指向Envoy Proxy地址的方式代理发起请求流量，经过Envoy Proxy的服务发现、负载均衡、路由等数据面逻辑后，选择目标服务实例地址进行流量转发；在Inbound流量接收端进行流量拦截（可配置是否拦截），对Inbound流量进行处理后转发至目标服务实例。,3、控制面以Pilot为核心组件。通过建立与Envoy Proxy双向GRPC连接，实现服务注册信息、服务治理策略的实时下发与同步。其他控制面组件Mixer（策略检查、监控、日志审计等）、Citadel（认证与授权）、Galley（配置检查）可在实际场景中配置关闭。,4、平台开放与扩展主要通过Kubernetes CRD与Mesh Configuration Protocol（简称为MCP，一套标准GRPC协议）。平台默认支持Kubernetes基于ETCD的注册中心机制，可通过MCP机制对接更多诸如Consul、Eureka、ZooKeeper等多注册中心；对服务治理策略的配置可通过定义Kubernetes CRD或实现MCP GRPC服务对接实现。,5、高可用设计主要基于Kubernetes及Istio机制实现。数据面Envoy Proxy以Init-Container方式与业务Container同时启动，Istio提供了Pilot-agent组件实现对Envoy Proxy生命周期、升级的支持，保证Envoy Proxy的高可用。控制面所有Istio组件均由Kubernetes多副本探针机制保证高可用性。Istio目前支持服务部署于Kubernetes、使用Consul注册服务、服务运行于单个虚拟机上集成，自定义 Istio的策略执行组件可以扩展和定制，以及与acl、日志记录、监视、配额、审核等现有解决方案集成。,6、Alibaba的对Istio架构的改造落地实践：https://zhuanlan.zhihu.com/p/96720618。,实践方案中放弃Istio 通过 iptables 的 NAT 表去做流量透明拦截的方式（NAT 表所使用到的 nf_contrack 内核模块效率很低），自研全新的透明拦截组件mangle；也没有采用 Istio 中的 Mixer 组件，用内部广泛使用的 Sentinel 组件替代，每个请求都会经过 Sentinel Filter 做处理。限流所需的配置信息则是通过 Pilot 从 Nacos 中获取，并通过 xDS 协议下发到 Envoy 中，实践中Service Mesh 的引入对于 RT 的影响和带来的 CPU 开销是基本一样的，而内存开销则因为依赖服务和集群规模的不同而有相当大的差异，Envoy 在内存的使用上仍存在很大的优化空间。,7、Service Mesh 离普及还面临一定挑战：,（1）性能尚存问题，服务间调用因为两层Sidecar，请求链路多两跳；Istio Mixer集中式后端成为性能瓶颈；,（2）Istio架构复杂，一定的技术门槛，掌握和实施成本较高，稳定性及产品化应用有待验证；,（3）真实落地的产品和企业还是比较少，提供的经验比较欠缺。,2018年10月24日， Apache软件基金会宣布Apache ServiceComb 毕业成为Apache顶级项目。Apache ServiceComb已在数十家企业中使用，包括奇蛙智能科技、华为云、软通动力，传智播客、梅斯医学、文思海辉、中国人保和同济大学等。,,,1、异步内核：基于VertX的同步和异步模型编程有效确保了无论是在传统企业或电商领域，还是在新兴的互联网或物联网等新兴企业中，都能够保持高性能和低延迟，以避免在达到峰值负载时应用出现雪崩效应；,2、ServiceComb支持多种通信协议, Rest、Highway（RPC）等，相比SpringCloud的Rest协议，Highway（RPC）协议性能更高，Highway是基于二进制的序列化方式传输数据，采用二进制编码的系统的性能远高于采用文本的HTTP协议；,3、开箱即用体验，开发简单，开发人员通过脚手架网站start.servicecomb.io启动的微服务项目，可以集服务注册、发现、通信和微服务治理能力和默认的集中化配置为一体；,4、ServiceComb的商业版本CSE相比SpringCloud不仅提供了微服务开发框架，还提供了微服务云部署，管理、治理等一站式解决方案；,5、OpenAPI自动代码生成，业务逻辑代码和治理能力隔离，可以使能DevOps Pipeline， 使用契约文件和OpenAPI的双向生成能力可以使不同的团队高效且独立的开发和管理代码、测试和进行文档化工作；,6、官网上的文档资料比较简略，网上可借鉴的实现案例不多，demo：https://blog.csdn.net/zengdongwen/article/details/93486257。