一、简介1.1微服务的目的是基于拆分和服务化，分解大量用户产生的大规模访问流量，采用分而治之的方法来实现用户指标所需的功能，同时满足用户对高可用性、高性能、可扩展性、扩展性和安全性的非功能性质量要求。1.2微服务核心要点业务功能划分：每个单一的业务功能称为一个服务，每个服务对应一个独立的功能团队。去中心化治理：微服务提倡去中心化治理，不建议每个微服务使用相同的标准和技术来开发和使用服务。交互方式：在微服务领域，微服务之间的交互是通过定义良好的接口实现的，不允许使用共享数据。通常使用RESTful风格的API或透明的RPC调用。组合依赖：根据业务流程处理的需要，按一定的顺序调用多个依赖的微服务，将依赖的微服务返回的数据进行组合、处理和转换，最终以一定的形式返回给用户。容错模式：熔断当一个服务的输入负载快速增加时，如果没有有效的措施来熔断负载，该服务将很快被淹没，被淹没的服务会导致所有依赖的服务被淹没，从而导致雪崩影响。因此，可以通过模拟家中的断路器，在微服务架构中实现熔断。对于突然增加的业务量，必须要有限流机制。限流机制一般控制访问的并发性，比如每秒允许并发处理的数量，查询量、请求量等，实现方式有计数器、令牌桶等。拆分粒度：按照微服务的初衷，服务应该按照业务功能进行拆分。知道每个服务的功能和职责单一，甚至不能拆分，这样每个服务都可以独立部署，扩容和缩容很方便，可以有效提高利用率。拆分的越细，服务之间的耦合越小，内聚性越好，越适合敏捷发布上线。1.3微服务的优缺点优点每个微服务都很小，可以专注于指定的业务功能或业务需求；微服务可以由2到5名开发人员组成的小团队独立开发；微服务是松散耦合且功能有意义的服务，在开发和部署阶段都是独立的；微服务可以用不同的语言开发；微服务易于被开发者理解、修改和维护，让小团队更关注自己的工作成果，不需要相互合作来体现价值；微服务允许您利用最新技术的集成；微服务只是业务逻辑代码，没有与HTML、CSS或其他界面组件混合。缺点微服务架构可能会带来过多的操作；需要DevOps技能；可以加倍努力；分布式系统可能很复杂且难以管理；因为分布式部署跟踪问题很困难；当服务数量增加时，管理复杂性增加。下面将介绍几种微服务架构的情况。2.SpringCloud2.1总体架构模块交互流程图2.2核心组件2.3特点1??SpringCloud利用SpringBoot的开发便利性，巧妙地简化了分布式系统基础设施的开发，组件支持丰富，功能完备，为开发者提供了一些快速开发的工具构建分布式系统，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策选举、分布式会话等，都可以使用SpringBoot开发一键启动部署风格;2??使用HTTP协议的RESTAPI，服务提供者和服务消费者通过Json数据格式进行交互，只需要定义相关的Json字段即可。提供者没有接口依赖性。通过注解实现服务配置，对程序有一定的侵入性；3??性能方面，因为是HTTP短连接，系统并发和响应时间不如RPC长连接（比如Dubbo，相差三倍左右），消息也比较小。对响应时间要求严格的场景不适合；4??使用springbootadmin作为基础服务监控，原理是SpringBootActuator组件；5??部分组件的功能和稳定性还没有达到量产级别，用户也不多，需要引入其他功能类似的组件。3、DubboDubbo是一个分布式、高性能、透明的RPC服务框架，提供服务自动注册、自动发现等高效多样的服务治理解决方案，并可与Spring框架无缝集成。3.1整体架构Provider：暴露服务的服务提供者；Consumer：调用远程服务的服务消费者，采用软负载均衡算法；Registry：服务注册和发现的注册中心，如Zookeeper、Redis等；监控：统计服务的调用次数和调用时间，服务消费者和提供者的监控中心，在内存中累计调用次数和调用时间，每分钟定时向监控中心发送统计数据；Container：服务运行容器；Dubbo层次结构设计图config配置层对外配置接口，以ServiceConfig和ReferenceConfig为中心，可以直接初始化配置类，也可以通过spring解析配置生成配置类；proxy服务代理层封装了所有接口的透明代理，而Invoker是其他层的中心，只有当它暴露给用户时，才使用Proxy将Invoker转换为接口，或者将接口实现转换为一个Invoker，也就是RPC可以在没有Proxy层的情况下运行，但是没有那么透明，不像本地服务那么调优。远程服务；Registry注册中心层封装了服务地址的注册和发现，以服务URL为中心，扩展接口为RegistryFactory、Registry、RegistryService；集群路由层封装了多个provider的路由和负载均衡，桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router、LoadBalance；monitor监控层RPC调用次数和调用时间监控以Statistics为中心，扩展接口为MonitorFactory、Monitor、MonitorService；协议远程调用层封装RPC调用，以Invocation，Result为中心，扩展接口为Protocol，Invoker，Exporter，Protocol是核心层，即只要有Protocol+Invoker+Exporter，非-可以完成透明的RPC调用，然后在Invoker进程中实现Filter拦截点；交换信息交换层封装了请求响应方式，从同步到异步，以Request和Response为中心，扩展接口有Exchanger、ExchangeChannel、ExchangeClient、Exchange服务器;transportnetwork传输层将mina和netty抽象为统一接口，以Message为中心，扩展接口有Channel、Transporter、Client、Server、Codec；serialize数据序列化层一些可复用的工具，扩展接口有Seri??alization,ObjectInput,ObjectOutput,ThreadPool3.2核心组件SpringCloud和Dubbo功能对比3.3特点4.SpringCloudAlibaba4.1整体架构与Springcloud类似，适应整合阿里巴巴各种中间件，注册中心换成Nacos，限流断路器从Hystrix换成Sentinel，服务间调用可以用Dubbo，消息总线用RocketMQ和事件-驱动组件，Seata组件（原fescar）用于支持分布式事务功能。最新版本是2.1.0.RELEASE。4.2核心组件及特性Nacos基本架构Sentinel的主要特性Sentinel的开源生态和springcloud相关组件对比几个服务治理组件对比使用demo：https://www.jianshu.com/p/9a8d94c0c90c。5、Servicemes5.1的整体架构如下，是一个简化的ServiceMesh架构。ServiceA和ServiceB相互调用，不是通过微服务框架直接相互指向，而是在中间加了两个Sidecars（边车）。)东西，各种服务都在这里处理数据上的逻辑。Sidecar充当数据平面的代理，靠近数据并受控制平面控制。基本架构图在实际业务中，尤其是在中台架构下，企业往往需要大量的微服务，即服务A和服务B的相互调用不断扩大，逐渐形成更多的服务与服务的组合sidecars，它成为一个真正的服务网格。服务网格（mesh）5.2核心组件Istio架构图主流的云原生ServiceMesh框架是Istio，它使用Go语言实现，与容器编排系统Kubernetes接轨。下面介绍主要部件。目前Istio版本为1.3.xrelease:5.3Feature1.ServiceMesh带来的核心价值可以概括为：基础设施下沉——微服务架构支撑、网络通信、治理等相关能力下沉到基础设施层，业务部门无需投入专门人员进行开发和维护。有效降低微服务架构下的研发和维护成本；降低升级成本——Sidecar支持热升级，降低中间件和技术框架客户端、SDK升级成本；语言无关——提供多语言服务治理能力；降低复杂测试和演练成本——降低全链路压测、故障演练、业务入侵等成本。2、数据平面使用EnvoyProxy作为代理组件。通过出站流量拦截或显示指向EnvoyProxy地址，proxy发起请求流量。经过EnvoyProxy的服务发现、负载均衡、路由等数据平面逻辑，选择目标服务实例地址进行流量转发；Inboundtraffic接收端发送trafficIntercept（可配置拦截或不拦截），对inbound流量进行处理并转发给目标服务实例。3、控制面以Pilot为核心组件。通过与EnvoyProxy建立双向GRPC连接，实现服务注册信息和服务治理策略的实时传递和同步。其他控制面组件Mixer（策略检查、监控、日志审计等）、Citadel（认证授权）、Galley（配置检查）在实际场景中可以配置为关闭。4.平台开放和扩展主要通过KubernetesCRD和MeshConfigurationProtocol（简称MCP，一套标准的GRPC协议）。平台默认支持Kubernetes基于ETCD的注册中心机制，可以通过MCP机制对接Consul、Eureka、ZooKeeper等更多注册中心；服务治理策略的配置可以通过定义KubernetesCRD或者实现MCPGRPC服务对接来实现。5、高可用设计主要基于Kubernetes和Istio机制实现。数据面的EnvoyProxy与Init-Container模式下的服务Container同时启动。Istio提供了Pilot-agent组件来支持EnvoyProxy的生命周期和升级，保证EnvoyProxy的高可用。控制平面上的所有Istio组件都通过Kubernetes多副本探测机制来保证高可用性。Istio目前支持部署在Kubernetes上的服务、使用Consul注册的服务以及运行在单个虚拟机上的集成服务。自定义Istio的策略执行组件可以扩展和自定义，以及现有的解决方案，例如acl、日志记录、监控、配额和审计。程序集成。6、阿里巴巴对Istio架构改造的实现：https://zhuanlan.zhihu.com/p/96720618。在实际方案中，Istio放弃了通过iptables的NAT表透明拦截流量的方式（NAT表中使用的nf_contrack内核模块效率很低），开发了新的透明拦截组件mangle；并且没有使用Istio中的Mixer组件。而不是内部广泛使用的Sentinel组件，每个请求都会由SentinelFilter处理。限流所需的配置信息通过Pilot从Nacos获取，通过xDS协议发送给Envoy。在实践中，引入ServiceMesh对RT的影响与CPU开销基本相同，而内存开销，但由于依赖服务和集群大小的差异，存在相当大的差异，Envoy仍有很大空间用于优化内存使用。七、ServiceMesh在普及之前还面临一定的挑战：（1）仍然存在性能问题。因为服务之间有两层sidecars，所以请求链接多了两跳；IstioMixer的中心化后端已经成为性能瓶颈；(2)Istio架构复杂，有一定的技术门槛，掌握和实施成本较高，稳定性和产品应用有待验证；（3）实际落地的产品和公司还比较少，提供的经验也比较缺乏。6.ServiceComb2018年10月24日，Apache软件基金会宣布ApacheServiceComb毕业，成为Apache顶级项目。ApacheServiceComb已经在包括奇瓦智能科技、华为云、软通动力、传智播客、梅斯医疗、文思海辉、人保财险、同济大学等数十家企业使用。6.1总体架构6.2核心组件6.3特点1.异步内核：基于VertX的同步异步模型编程有效保证无论在传统企业还是电商领域，还是在新兴互联网或物联网等新兴企业，都可以保持高性能和低延迟，避免应用在达到峰值负载时出现雪崩效应；2、ServiceComb支持多种通信协议，Rest、Highway(RPC)等，相对于SpringCloud的Rest协议，Highway(RPC)协议性能更高，Highway是基于二进制序列化来传输数据的。使用二进制编码的系统性能远高于使用文本的HTTP协议；3、开箱即用的体验，轻松开发，开发者通过脚手架网站start.servicecomb.io启动微服务项目，可以集成服务注册、发现、通信和微服务治理能力以及默认集中配置；4、与SpringCloud相比，ServiceComb的商业版CSE不仅提供了微服务开发框架，还提供了微服务云部署、管理、治理等一站式解决方案；5.OpenAPI自动代码生成，业务逻辑代码与治理能力隔离，可赋能DevOpsPipeline，使用合约文件和OpenAPI双向生成能力可以让不同团队高效且独立地开发和管理代码、测试和文档；6、官网文档比较简单，网上能参考的实现案例不多。演示：https://blog.csdn.net/zengdongwen/article/details/93486257。
