单体应用与微服务架构、SpringCloud与Dubbo

1 单体应用与微服务

1.1 单体应用（Monolith）架构

1.1.1 什么是单体应用

项目所有的资源都在一个应用中，打包成一个war包，使用一个服务器去运行，运行再一个进程中。

1.1.2 单体应用的优点

• 成本较低
• 技术要求相比微服务架构相对较低
• 部署比较简单，由于是打包为一个war包，所以部署会比较简单

1.1.3 单体应用的缺点

• 一个模块出现问题，那么整个项目都会出现问题。
• 单个服务器能处理的并发有限，可以做集群，但是不方便局部扩展（只某一个模块扩展）。
• 复杂性高，随着业务的不断迭代，项目的代码量会急剧的增多，项目模块也会随着而增加，模块与模块之间的关系就会变成的很复杂，整个项目就会变成的非常复杂，在新增和修改代码的时候都会做很多的测试，很容易会由于一处的变动影响之前业务的功能。
• 技术选型单一，只能选定一种语言开发。
• 数据库选型单一，不能连接多种数据库。

1.2 微服务（MicroService）架构

1.2.1 什么是微服务架构

微服务就是把一个大的系统，拆分成多个小的服务，每个微服务只专注一个业务 ，每个服务有各自的进程， 微服务之间使用网络通信协议进行数据交互(通常是基于HTTP的RESTful API)。

1.2.2 微服务的优点

• 数据库选型多样化，不同的微服务可以选择不同种类的数据库。
• 技术选型多样化，不同的微服务可以使用不同的语言、技术，只需要提供微服务间的数据通信即可。
• 职能单一，每个微服务只需要专注一个业务。
• 方便做局部扩展
• 便于维护
• 一个模块出现问题，其他服务任然可用

1.2.3 微服务的缺点

• 成本较高
• 技术要求较高
• 部署相对麻烦

单体应用与微服务示意图：

1.2.4 微服务的远程调用方式

在微服务中服务间的远程调用。那么服务间的远程调用方式有哪些呢？
常见的远程调用方式有以下几种：

• RPC：Remote Produce Call远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型。
• Http：http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。
  现在热门的Rest风格，就可以通过http协议来实现。

1.2.5 RPC

RPC，即 Remote Procedure Call（远程过程调用），是一个计算机通信协议。 该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。说得通俗一点就是：A计算机提供一个服务，B计算机可以像调用本地服务那样调用A计算机的服务。

通过上面的概念，我们可以知道，实现RPC主要是做到两点：

• 实现远程调用其他计算机的服务
  • 要实现远程调用，肯定是通过网络传输数据。A程序提供服务，B程序通过网络将请求参数传递给A，A本地执行后得到结果，再将结果返回给B程序。这里需要关注的有两点：
    • 1）采用何种网络通讯协议？
      • 现在比较流行的RPC框架，都会采用TCP作为底层传输协议
    • 2）数据传输的格式怎样？
      • 两个程序进行通讯，必须约定好数据传输格式。就好比两个人聊天，要用同一种语言，否则无法沟通。所以，我们必须定义好请求和响应的格式。另外，数据在网路中传输需要进行序列化，所以还需要约定统一的序列化的方式。
• 像调用本地服务一样调用远程服务
  • 如果仅仅是远程调用，还不算是RPC，因为RPC强调的是过程调用，调用的过程对用户而言是应该是透明的，用户不应该关心调用的细节，可以像调用本地服务一样调用远程服务。所以RPC一定要对调用的过程进行封装

RPC调用流程图：

1.2.6 Http

Http协议：超文本传输协议，是一种应用层协议。规定了网络传输的请求格式、响应格式、资源定位和操作的方式等。但是底层采用什么网络传输协议，并没有规定，不过现在都是采用TCP协议作为底层传输协议。说到这里，大家可能觉得，Http与RPC的远程调用非常像，都是按照某种规定好的数据格式进行网络通信，有请求，有响应。没错，在这点来看，两者非常相似，但是还是有一些细微差别。

• RPC并没有规定数据传输格式，这个格式可以任意指定，不同的RPC协议，数据格式不一定相同。
• Http中还定义了资源定位的路径，RPC中并不需要
• 最重要的一点：RPC需要满足像调用本地服务一样调用远程服务，也就是对调用过程在API层面进行封装。Http协议没有这样的要求，因此请求、响应等细节需要我们自己去实现。
  • 优点：RPC方式更加透明，对用户更方便。Http方式更灵活，没有规定API和语言，跨语言、跨平台
  • 缺点：RPC方式需要在API层面进行封装，限制了开发的语言环境。

例如我们通过浏览器访问网站，就是通过Http协议。只不过浏览器把请求封装，发起请求以及接收响应，解析响应的事情都帮我们做了。如果是不通过浏览器，那么这些事情都需要自己去完成。
Http调用流程图：

1.2.7 如何选择

既然两种方式都可以实现远程调用，我们该如何选择呢？

• 速度来看，RPC要比http更快，虽然底层都是TCP，但是http协议的信息往往比较臃肿，不过可以采用gzip压缩。
• 难度来看，RPC实现较为复杂，http相对比较简单
• 灵活性来看，http更胜一筹，因为它不关心实现细节，跨平台、跨语言。

因此，两者都有不同的使用场景：

• 如果对效率要求更高，并且开发过程使用统一的技术栈，那么用RPC还是不错的。 dubbo
• 如果需要更加灵活，跨语言、跨平台，显然http更合适 springcloud
  那么我们该怎么选择呢？
  微服务，更加强调的是独立、自治、灵活。而RPC方式的限制较多，因此微服务框架中，一般都会采用基于Http的Rest风格服务。

1.2.8 Http客户端工具

既然微服务选择了Http，那么我们就需要考虑自己来实现对请求和响应的处理。不过开源世界已经有很多的http客户端工具，能够帮助我们做这些事情，例如：

• HttpClient
• OKHttp
• URLConnection
  -Spring的RestTemplate
  Spring提供了一个RestTemplate模板工具类，对基于Http的客户端进行了封装，并且实现了对象与json的序列化和反序列化，非常方便。RestTemplate并没有限定Http的客户端类型，而是进行了抽象，目前常用的3种都有支持：
• HttpClient
• OkHttp
• JDK原生的URLConnection（默认的）

1.3 选型

单体应用架构：中小型项目(功能相对较少) crm 档案管理 库存管理,公司官网等
微服务架构：大型项目（功能比较多） 商城 erp,人力资源等

2 Spring Cloud 概述

2.1 什么是Spring Cloud

Spring cloud是一个基于Spring Boot实现的服务治理工具包，用于微服务架构中管理和协调服务的。

2.2 组成部分

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Springcloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。
以下是主要组成部分：

其中SpringCloud重要的五大组件：

• 注册中心（Netflix Eureka）
• 客服端负载均衡（Netflix Ribbon\Feign）
• 断路器（Netflix Hystrix）
• 服务网关（Netflix Zuul）
• 分布式配置（Spring Cloud Config）

所有组成：

• 1、Spring Cloud Config 配置中心，利用git集中管理程序的配置。
• 2、Spring Cloud Netflix 集成众多Netflix的开源软件。
• 3、Spring Cloud Bus 消息总线，利用分布式消息将服务和服务实例连接在一起，用于在一个集群中传播状态的变化 。
• 4、Spring Cloud for Cloud Foundry 利用Pivotal Cloudfoundry集成你的应用程序。
• 5、Spring Cloud Cloud Foundry Service Broker 为建立管理云托管服务的服务代理提供了一个起点。
• 6、Spring Cloud Cluster 基于Zookeeper, Redis, Hazelcast, Consul实现的领导选举和平民状态模式的抽象和实现。
• 7、Spring Cloud Consul 基于Hashicorp Consul实现的服务发现和配置管理。
• 8、Spring Cloud Security 在Zuul代理中为OAuth2 rest客户端和认证头转发提供负载均衡
• 9、Spring Cloud Sleuth SpringCloud应用的分布式追踪系统，和Zipkin，HTrace，ELK兼容。
• 10、Spring Cloud Data Flow 一个云本地程序和操作模型，组成数据微服务在一个结构化的平台上。
• 11、Spring Cloud Stream 基于Redis,Rabbit,Kafka实现的消息微服务，简单声明模型用以在Spring Cloud应用中收发消息。
• 12、Spring Cloud Stream App Starters 基于Spring Boot为外部系统提供spring的集成
• 13、Spring Cloud Task 短生命周期的微服务，为SpringBooot应用简单声明添加功能和非功能特性。
• 14、Spring Cloud Task App Starters
• 15、Spring Cloud Zookeeper 服务发现和配置管理基于Apache Zookeeper。
• 16、Spring Cloud for Amazon Web Services 快速和亚马逊网络服务集成。
• 17、Spring Cloud Connectors 便于PaaS应用在各种平台上连接到后端像数据库和消息经纪服务。
• 18、Spring Cloud Starters （项目已经终止并且在Angel.SR2后的版本和其他项目合并）
• 19、Spring Cloud CLI 插件用Groovy快速的创建Spring Cloud组件应用。
  当然还在不断地增加。

2.3 SpringCloud与Dubbo

1)从两个公司的背景来谈：Dubbo，是阿里巴巴服务化治理的核心框架，并被广泛应用于中国各互联网公司；Spring Cloud是大名鼎鼎的Spring家族的产品。阿里巴巴是一个商业公司，虽然也开源了很多的顶级的项目，但从整体战略上来讲，仍然是服务于自身的业务为主。Spring专注于企业级开源框架的研发，不论是在中国还是在世界上使用都非常广泛，开发出通用、开源、稳健的开源框架就是他们的主业。

2）从社区活跃度这个角度来对比，Dubbo虽然也是一个非常优秀的服务治理框架，并且在服务治理、灰度发布、流量分发这方面做的比Spring Cloud还好，除过当当网在基础上增加了rest支持外，已有两年多的时间几乎都没有任何更新了。在使用过程中出现问题，提交到github的Issue也少有回复。

相反Spring Cloud自从发展到现在，仍然在不断的高速发展，从github上提交代码的频度和发布版本的时间间隔就可以看出，现在Spring Cloud即将发布2.0版本，到了后期会更加完善和稳定。

3. 从整个大的平台架构来讲，dubbo框架只是专注于服务之间的治理，如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成，这样无形中使用dubbo的难度就会增加。Spring Cloud几乎考虑了服务治理的方方面面，更有Spring Boot这个大将的支持，开发起来非常的便利和简单。

4）从技术发展的角度来讲，Dubbo刚出来的那会技术理念还是非常先进，解决了各大互联网公司服务治理的问题，中国的各中小公司也从中受益不少。经过了这么多年的发展，互联网行业也是涌现了更多先进的技术和理念，Dubbo一直停滞不前，自然有些掉队，有时候我个人也会感到有点可惜，如果Dubbo一直沿着当初的那个路线发展，并且延伸到周边，今天可能又是另一番景象了。

Spring 推出Spring Boot/Cloud也是因为自身的很多原因。Spring最初推崇的轻量级框架，随着不断的发展也越来越庞大，随着集成项目越来越多，配置文件也越来越混乱，慢慢的背离最初的理念。随着这么多年的发展，微服务、分布式链路跟踪等更多新的技术理念的出现，Spring急需一款框架来改善以前的开发模式，因此才会出现Spring Boot/Cloud项目，我们现在访问Spring官网，会发现Spring Boot和Spring Cloud已经放到首页最重点突出的三个项目中的前两个，可见Spring对这两个框架的重视程度。

总结一下，dubbo曾经确实很厉害，但是Spring Cloud是站在近些年技术发展之上进行开发，因此更具技术代表性。

2018年2月9日，Apache 基金会的邮件列表上发起了讨论是否接纳阿里的Dubbo 项目进入 Apache 孵化器的投票。
2018年2月15日，邮件列表显示，Dubbo 获得了 14 张赞成票，在无弃权和反对票的情况下，正式通过投票，顺利成为 Apache 基金会孵化项目。