云服务器微服务架构的全面概述：打破复杂性的神话 (云服务器部署微服务)

在当今快速发展的数字时代，企业需要灵活且可扩展的应用程序来满足不断变化的客户需求。微服务架构已成为构建此类应用程序的流行方法，尤其是在云服务器环境中。

什么是微服务？

微服务是一种应用设计方法，它将应用程序分解成小而独立的模块，称为微服务。每个微服务执行特定功能，并且可以单独部署、扩展和维护。

云服务器与微服务

云服务器为微服务架构提供了理想的平台，因为它们提供了：

微服务入门｜微服务架构怎么设计

将一个单体应用拆分成一组微小的服务组件，每个微小的服务组件运行在自己的进程上，组件之间通过如RESTful API这样的轻量级机制进行交互，这些服务以业务能力为核心，用自动化部署机制独立部署，另外，这些服务可以用不同的语言进行研发，用不同技术来存储数据 。

通过以上的定义描述，我们可以基本确定给出微服务的节特征：

用微服务来进行实践到生产项目中，首先要考虑一些问题。比如下图的微服务业务架构：

在上图图表展示的架构图中，我们假设将业务商户服务A、订单服务B和产品服务C分别拆分为一个微服务应用，单独进行部署。此时，我们面临很多要可能出现的问题要解决，比如：

1、客户端如何访问这些服务？

2、每个服务之间如何进行通信？

3、多个微服务，应如何实现？

4、如果服务出现异常宕机，该如何解决？

以上这些都是问题，需要一个个解决。

在单体应用开发中，所有的服务都是本地的，前端UI界面，移动端APP程序可以直接访问后端服务器程序。

现在按功能拆分成独立的服务，跑在独立的进程中。如下图所示：

此时，后台有N个服务，前台就需要记住管理N个服务，一个服务 下线 、 更新 、 升级 ，前台和移动端APP就要重新部署或者重新发包，这明显不服务我们拆分的理念。

尤其是对当下业务需求的飞速发展，业务的变更是非常频繁的。

除了访问管理出现困难以外，N个小服务的调用也是一个不小的网络开销。

另外，一般微服务在系统内部，通常是无状态的，而我们的用户在进行业务操作时，往往是跨业务模块进行操作，且需要是有状态的，在此时的这个系统架构中，也无法解决这个问题。

传统的用来解决用户登录信息和权限管理通常有一个统一的地方维护管理（OAuth），我们称之为授权管理。

基于以上列出的问题，我们采用一种叫做网关（英文为API Gateway）的技术方案来解决这些问题，网关的作用主要包括：

网关(API Gateway)可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个的服务端。

他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为 单点故障 点或者性能的瓶颈。

最终，添加了网关(API Gateway)的业务架构图变更为如下所示：

所有的微服务都是独立部署，运行在自己的进程容器中，所以微服务与微服务之间的通信就是IPC（Inter Process Communication），翻译为进程间通信。

进程间通信的方案已经比较成熟了，现在最常见的有两大类： 同步调用、异步消息调用 。

同步调用

同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。同步调用的有两种实现方式：分别是 REST 和 RPC

基于REST和RPC的特点，我们通常采用的原则为： 向系统外部暴露采用REST，向系统内部暴露调用采用RPC方式。

异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。

需要付出的代价是一致性的减弱，需要接受数据 最终一致性 ，所谓的最终一致性就是只可能不会立刻同步完成，会有延时，但是最终会完成数据同步；还有就是后台服务一般要实现 幂等性 ，因为消息发送由于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）。

最后就是必须引入一个独立的 Broker，作为中间代理池。

常见的异步消息调用的框架有：Kafaka、Notify、MessageQueue。

最终，大部分的服务间的调用架构实现如下所示：

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。

一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。

这就出现了新的问题：

这就是服务的发现、识别与管理问题。

解决多服务之间的识别，发现的问题一般是通过注册的方式来进行。

具体来说：当服务上线时，服务提供者将自己的服务注册信息注册到某个专门的框架中，并通过心跳维持长链接，实时更新链接信息。

服务调用者通过服务管理框架进行寻址，根据特定的算法，找到对应的服务，或者将服务的注册信息缓存到本地，这样提高性能。

当服务下线时，服务管理框架会发送服务下线的通知给其他服务。

常见的服务管理框架有：Zookeeper等框架。

如上的问题解决方案有两种具体的实现，分别是： 基于客户端的服务注册与发现 、 基于服务端的服务注册与发现 。

优点是架构简单，扩展灵活，只对服务注册器依赖。

缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持。

优点是所有服务对于前台调用方透明，一般小公司在云服务上部署的应用采用的比较多。

前面提到，单体应用开发中一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。

而分布式最大的特性就是网络是不可靠的。

通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。

因此，当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多，比如说：

微服务构架有哪些?

微服务架构已经成为全球各行各业IT架构转型的热门选择。

本文为您梳理了当前最热门的微服务框架，旨在为开发者提供快速入门和深入理解的资源。

13个Java微服务框架

Spring Boot

Java程序员首选的微服务架构，因其简化配置、快速启动和丰富的集成工具而备受欢迎。

Spring Boot通过内置功能，使开发者能够专注于业务逻辑，而无需过多关注配置细节。

它提供的JAR文件易于部署，与Docker容器具有很高的兼容性，深受构建微服务的开发者喜爱。

Spring Boot遵循MVC设计理念，与Spring生态系统深度集成，支持主要数据存储、LDAP服务器和消息传递工具如Apache Kafka。

此外，Spring Boot拥有诸多小工具，如Spring Vault，用于安全存储密码，进一步增强了开发者的体验。

Eclipse MicroProfile

微服务架构的简化版本，由Java Enterprise社区开发，旨在快速构建简单的微服务。

MicroProfile提供了REST请求处理、JSON解析和依赖注入等功能，且易于上手。

它每季度发布新版本，持续完善以保持微服务的平稳运行。

Dropwizard

Dropwizard提供了一个简洁的微服务框架，包含多个模块，允许开发者根据需求添加业务逻辑。

它能够快速构建且生成的JAR文件体积小巧，启动速度极快，适用于对代码整洁度和松耦合性有高要求的场景。

WildFly Thorntail

Red Hat团队开发的微服务框架，通过灵活的配置工具构建，支持MicroProfile标准。

它允许开发者自定义构建文件，通过扫描代码检测组件，并使用BOM文件覆盖，最终生成轻量级JAR文件，易于部署。

去除了Java Enterprise Edition中的复杂性，保留轻量级的核心功能，适用于构建高性能的微服务。

Helidon提供多种版本，如SE和MP，支持Netty和JAX-RS，并集成了备受好评的工具，吸引众多开发者。

一个用于快速API开发的轻量级框架，包含键值数据存储等特性，避免了连接数据库的复杂性。

Cricket易于集成到现有项目中，支持多种文件格式，方便快捷。

更多微服务框架

Swagger提供了一套API规范语言，简化了API设计、测试和文档化过程。

它支持自动化测试和API治理，适用于多种编程语言，包括Java，增强了微服务的可维护性和可扩展性。

Restlet框架提供了丰富的API连接，支持多种库和工具，如JavaMail、Lucene和Solr。

它支持XML、CSV和其他文件格式，且具备本地测试API的功能。

Squash为Kubernetes集群上的微服务提供了调试工具，允许开发者在本地IDE中设置断点，接收系统运行数据，简化了复杂微服务的调试过程。

Telepresence

Telepresence创建本地代理来模拟远程Kubernetes集群上的微服务，支持在本地计算机上设置断点或执行操作，极大地提高了开发和调试效率。

Zipkin收集和查询微服务事件，用于监控和故障排查。

它支持多种语言实现，可集成到如Spring等框架中，适用于多语言系统。

Python微服务框架

阿里巴巴开源的分布式服务框架，提供高性能的RPC远程服务调用和SOA服务治理。

Dubbo适用于复杂业务的高并发挑战，已被多家知名企业采用。

Zero是一个高性能、快速构建的Python微服务框架，支持RPC和Pub/Sub接口。

其特性包括使用zeromq实现快速通信、支持消息通信和异步操作。

Nameko采用异步通信方式构建微服务，基于RabbitMQ作为消息中间件，简单易用。

更多推荐框架

Akka是一个用于Java和Scala的Actor模型库，适用于构建容错、高可伸缩性的微服务集群。

Core专为模块化微服务架构设计，支持跨平台应用程序开发。

Service Fabric

Service Fabric是微软开发的微服务框架，常用于Azure上的云服务。

行云创新提供了《信创微服务平台建设指南》，为企业提供微服务架构转型和平台落地的参考建议。

有兴趣的朋友可免费下载。

了解更多详情，请点击下方链接获取《信创微服务平台建设指南》。

阿里微服务框架dubbo(阿里的微服务框架)

Dubbo分布式服务框架介绍

随着业务的发展、用户量的增长、系统并发访问需求越来越大，系统数量增多，调用依赖关系也变得复杂，为了确保系统高可用、高并发的要求，系统的架构也从单体时代慢慢迁移至服务SOA时代，根据不同服务对系统资源的要求不同，我们可以更合理的配置系统资源，使系统资源利用率最大化。

而Dubbo则是SOA服务化治理方案的一个核心框架。

Dubbo作为阿里巴巴内部的SOA服务化治理方案的核心框架，在2012年时已经每天为2000+个服务提供3,000,000,000+次访问量支持，并被广泛应用于阿里巴巴集团的各成员站点。

Dubbo自2011年开源后，已被许多非阿里系公司使用，其中既有当当网、网易考拉等互联网公司，也有中国人寿、青岛海尔等传统企业。

Dubbo是一个高性能服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，使得应用可通过高性能RPC实现服务的输出和输入功能，和Spring框架可以无缝集成。

作为一个分布式服务框架，以及SOA治理方案，Dubbo其功能主要包括：

Dubbo最大的特点是按照分层架构思维构建应用服务，使用这种方式可以使各个层之间解耦合（或者最大限度地松耦合）。

从服务模型的角度来看，Dubbo采用的是一种非常简单的模型，要么是提供方提供服务，要么是消费方消费服务，所以基于这一点可以抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。

Dubbo包含远程通讯、服务集群和服务发现与注册三个核心部分。

提供透明化的远程方法调用，实现像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

同时具备软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

可以实现服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。

Dubbo服务组件调用关秕说明：

Dubbo框架设计一共划分了10个层，而最上面的Service层是留给实际想要使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。

图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。

下面，结合Dubbo官方文档，我们分别理解一下框架分层架构中，各个层次的设计要点：

从上图可以看出，Dubbo对于服务提供方和服务消费方，从框架的10层中分别提供了各自需要关心和扩展的接口，构建整个服务生态系统（服务提供方和服务消费方本身就是一个以服务为中心的）。

根据官方提供的，对于上述各层之间关系的描述，如下所示：

Dubbo协议

Dubbo是Alibaba开源的分布式服务框架远程调用框架，在网络间传输数据，就需要通信协议和序列化。

Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多种协议，但是Dubbo官网是推荐我们使用Dubbo协议的，默认也是用的dubbo协议。

先介绍几种常见的协议：

缺省协议，使用基于mina1.1.7+hessian3.2.1的tbremoting交互。

连接个数：单连接

连接方式：长连接

传输协议：TCP

传输方式：NIO异步传输

序列化：Hessian二进制序列化

适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用dubbo协议传输大文件或超大字符串。

适用场景：常规远程服务方法调用

1、dubbo默认采用dubbo协议，dubbo协议采用单一长连接和NIO异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况

2、他不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。

配置如下：

dubbo:protocolname=dubboport=/

dubbo:protocolname=“dubbo”port=“9090”server=“netty”client=“netty”codec=“dubbo”

serialization=“hessian2”charset=“UTF-8”threadpool=“fixed”threads=“100”queues=“0”iothreads=“9”

buffer=“8192”accepts=“1000”payload=“”/

3、Dubbo协议缺省每服务每提供者每消费者使用单一长连接，如果数据量较大，可以使用多个连接。

dubbo:protocolname=dubboconnections=2/

4、为防止被大量连接撑挂，可在服务提供方限制大接收连接数，以实现服务提供方自我保护

dubbo:protocolname=dubboaccepts=1000/

Java标准的远程调用协议。

连接个数：多连接

连接方式：短连接

传输协议：TCP

传输方式：同步传输

序列化：Java标准二进制序列化

适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。

适用场景：常规远程服务方法调用，与原生RMI服务互操作

RMI协议采用JDK标准的.*实现，采用阻塞式短连接和JDK标准序列化方式。

基于Hessian的远程调用协议。

连接个数：多连接

连接方式：短连接

传输协议：HTTP

传输方式：同步传输

序列化：表单序列化

适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。

适用场景：需同时给应用程序和浏览器JS使用的服务。

1、Hessian协议用于集成Hessian的服务，Hessian底层采用Http通讯，采用Servlet暴露服务，Dubbo缺省内嵌Jetty作为服务器实现。

2、Hessian是Caucho开源的一个RPC框架：，其通讯效率高于WebService和Java自带的序列化。

基于http表单的远程调用协议。参见：[HTTP协议使用说明]

连接个数：多连接

连接方式：短连接

传输协议：HTTP

传输方式：同步传输

序列化：表单序列化

适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。

适用场景：需同时给应用程序和浏览器JS使用的服务。

基于WebService的远程调用协议。

连接个数：多连接

连接方式：短连接

传输协议：HTTP

传输方式：同步传输

序列化：SOAP文本序列化

适用场景：系统集成，跨语言调用

序列化是将一个对象变成一个二进制流就是序列化，反序列化是将二进制流转换成对象

为什么要序列化？

Dubbo序列化支持java、compactedjava、nativejava、fastjson、dubbo、fst、hessian2、kryo，其中默认hessian2。

其中java、compactedjava、nativejava属于原生java的序列化。

hessian2序列化：hessian是一种跨语言的高效二进制序列化方式。

但这里实际不是原生的hessian2序列化，而是阿里修改过的，它是dubboRPC默认启用的序列化方式。

json序列化：目前有两种实现，一种是采用的阿里的fastjson库，另一种是采用dubbo中自己实现的简单json库，但其实现都不是特别成熟，而且json这种文本序列化性能一般不如上面两种二进制序列化。

java序列化：主要是采用JDK自带的Java序列化实现，性能很不理想。

阿里研发后开源，Dubbo成Apache基金会顶级项目

近日，基于Java的开源远程过程调用框架ApacheDubbo正在逐渐从Apache孵化器升级到顶级项目（TLP）。

该项目最初是由阿里开发的，并于2011年开源。

它于去年年初进入了Apache孵化器。

Apache软件基金会表示，Dubbo框架可以指定可跨分布式或微服务系统远程调用的方法，其主要功能是：基于接口的远程调用；容错和负载均衡；自动服务注册和发现。

最近加入TLP排名的其他项目包括基于标准的客户数据平台ApacheUnom和用于创建和管理大数据的可扩展工作流自动化和调度系统ApacheAirflow。

dubbo和eureka的区别

dubbo和springcloud区别是：

1、初始定位不同：

SpringCloud定位为微服务架构下的一站式解决方案；Dubbo是SOA时代的产物，它的关注点主要在于服务的调用和治理。

2、生态环境不同：

SpringCloud依托于Spring平台，具备更加完善的生态体系；而Dubbo一开始只是做RPC远程调用，生态相对匮乏，现在逐渐丰富起来。

3、调用方式：

SpringCloud是采用Http协议做远程调用，接口一般是Rest风格，比较灵活；Dubbo是采用Dubbo协议，接口一般是Java的Service接口，格式固定。

但调用时采用Netty的NIO方式，性能较好。

4、组件差异：

例如SpringCloud注册中心一般用Eureka，而Dubbo用的Zookeeper，SpringCloud生态丰富，功能完善，更像是品牌机，Dubbo则相对灵活，可定制性强，更像是组装机。

5、SpringCloud：

Spring公司开源的微服务框架，SpirngCloud定位为微服务架构下的一站式解决方案。

阿里巴巴开源的RPC框架，Dubbo是SOA时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和熔断。

两者的生态对比：

1、SpringCloud的功能很明显比Dubbo更加强大，涵盖面更广，而且作为Spring的旗舰项目，它也能够与SpringFramework、SpringBoot、SpringData、SpringBatch等其他Spring项目完美融合，这些对于微服务而言是至关重要的。

2、使用Dubbo构建的微服务架构就像组装电脑，各环节选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心。

3、而SpringCloud就像品牌机，在SpringSource的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础原理有足够的了解。

目前比较流程的微服务开发框架是?

SpringBoot的设计目的是简化新Spring应用初始搭建以及开发过程，2017年有64.4%的受访者决定使用SpringBoot，可以说是最受欢迎的微服务开发框架。

利用SpringBoot开发的便捷度简化分布式系统基础设施的开发，比如像配置中心、注册、负载均衡等方面都可以做到一键启动和一键部署。

SpringCloud是一个系列框架的合计，基于HTTP（s）的RETS服务构建服务体系，SpringCloud能够帮助架构师构建一整套完整的微服务架构技术生态链。

Dubbo是由阿里巴巴开源的分布式服务化治理框架，通过RPC请求方式访问。

Dubbo是在阿里巴巴的电商平台中逐渐探索演进所形成的，经历过复杂业务的高并发挑战，比SpringCloud的开源时间还要早。

目前阿里、京东、当当、携程、去哪等一些企业都在使用Dubbo。

Dropwizard将Java生态系统中各个问题域里最好的组建集成于一身，能够快速打造一个Rest风格的后台，还可以整合Dropwizard核心以外的项目。

国内现在使用Dropwizard还很少，资源也不多，但是与SpringBoot相比，Dropwizard在轻量化上更有优势，同时如果用过Spring，那么基本也会使用SpringBoot。

Akka是一个用Scala编写的库，可以用在有简化编写容错、高可伸缩性的Java和Scala的Actor模型，使用Akka能够实现微服务集群。

.x/Lagom/ReactiveX/Spring5

这四种框架主要用于响应式微服务开发，响应式本身和微服务没有关系，更多用于提升性能上，但是可以和微服务相结合，也可以提升性能。

相关微服务框架

是专门针对模块化微服务架构设计的，是跨平台应用程序开发框架，是微软开发的第一个官方版本。

ServiceFabric是微软开发的一个微服务框架，基于ServiceFabric构建的很多云服务被用在了Azure上。

Surging是基于RPC协议的分布式微服务技术框架，基于而来。

MicrodotFramework用于编写定义服务逻辑代码，不需要解决开发分布式系统的挑战，能够很方便的进行MicrosoftOrleans集成。