SpringCloud——微服务概述和与Dubbo的对比

单体架构

在传统的软件架构中，经常提到MVC架构，模型，也就是模型视图控制器，即数据访问层，视图层和控制器层。
开发服务器的软件一般都是按照MVC架构来设计的，其主要的功能包括响应用户的交互，对业务逻辑的操作，对数据库的增删改查，虽然有三层模型的划分，但是只是在软件架构上的分层，并没有对于业务层进行分层。也就是说一个单体架构就是将视图层，业务逻辑层和控制器层和模型层全部在一个工程中，开发完成之后把他们打包为jar包或者war包，最终部署到一台服务器上面。
拥有许多优点

易于开发 易于测试 易于部署

集群架构

随着业务的发展，系统的压力越来越大，对设备的配置要求也就越高，需要很昂贵的服务器。当时提出了两点解决方案

• 机器昂贵则化整为零，比如说一台昂贵的电脑用多台低端的电脑来代替
• 资源浪费则将配置进行适当的增加，比如双十一的时候

将许多普通的PC集群到一起，这就是集群架构，通过增加负载均衡服务器。负载均衡往往对外暴露了一个统一的接口，让外界用户感觉这是在向同一台服务器中发送请求，而实际上通过负t载均衡已经将请求分别发送到了后端不同的服务器上面
那么有了统一的接口，就可以在这个入口进行流量清理，方式DDoS攻击

弊端随之显现
集群架构虽然具备一定的处理搞并发的能力改善了系统的性能，但是从业务的的角度来看，它依然是部署到不同机器上一模一样的架构，本质上来说还是单体架构

• 开发风险高
• 测试成本高
• 部署频率低

由于我们例如在升级过程中，每台服务器都要进行修改，重复建设是不可取的，所以微服务诞生了

微服务架构

为了解决单体应用的缺点，，我们将原来大的单体项目进行拆分，化整为零形成独立的应用，不过此时这些应用没有直观的入口，因此用传统应用的概念来定义就不太妥当了，于是诞生了服务 通过服务来描述这种功能性的应用。并为其他的应用提供功能支持，服务于其他应用

服务：只要能向其他组件提供技术支撑的系统都叫做服务，甚至出现了许多的概念，比如 SaaS（软件即服务）PaaS（平台即服务）IaaS（基础架构即服务）

也就是说我们把业务分成若干个服务避免重复工作，那么后续应用的开发就是服务的开发

从技术的角度来看，微服务就是将传统的一站式应用，根据不同的业务拆分成一个小的服务，每个服务提供独立的业务功能，拥有独立的存储（数据库或者缓存）通过服务之间互相协调来完成复杂的系统功能

微服务特性

1. 服务组件化

组件是独立的，可替换，可升级的软件单元，将整体应用拆分为独立的服务器组件后，当对单个组件的修改完成之后，只需要重新部署该组件即可。这样不是绝对的，有一些改动会影响服务器间的接口，调用方也需要进行相应的修改和部署，所以好多微服务架构的目标是高内聚，低耦合

2. 围绕业务能力组建团队

在微服务项目中，团队是围绕业务来进行组织的

3. 产品不是项目

在大部分软件开发的时候，采用的都是项目的形式，开发团队完成开发之后，将团队软件进行运维去处理，原来的项目完成之后，项目团队就解散了。微服务倾向于避免这样的模式

4. 去中心化的操作

在单体应用中，数据都在一个数据库中，管理难度较大，不同的业务逻辑放到了不同的服务所对应的数据库中

5. 分散治理

大服务被拆成小服务，所以每个服务都可以根据自己的需求，采用合适的编程技术实现方案

微服务的实践参考

我们在实际生产中如何f进行微服务的拆分，微服务到底如何定界，服务拆分之后如何进行协作？

1. 服务如何拆分？

明确定义好微服务系统的边界

2. 服务间的通信

服务拆分好之后，完成了开发就可以部署到独立的服务器上了，而服务之间是需要通信的，一半倾向于使用哦个HTTP协议通信，大部分采用RESTFUL风格，这种通信机制与平台和语言无关，因此可以调用跨语言的微服务

3. 每个服务的数据库分别独立

按照业务来拆分，数据库也就对应的独立了

微服务的缺点与发展

1. 增加了系统的复杂度

将单体应用拆分成微服务之后，开发人员要花时间和精力去学习更多的框架只是，网络调用频繁会带来延时，出错的风险，虽然说服务之间是解耦的，但是如果修改一个服务影响到了其他服务的调用，就会带来不必要的麻烦

2.分布式一致性

当服务里只有一个数据库时，单一数据库我们可以保证数据库的一致性，现在在微服务中，是多个服务多个数据库，则数据的一致性和可用性无法同时满足，一般微服务为了可用性，会牺牲掉一致性

3. 增加系统的开销

服务调用会涉及服务之间的地址的管理，需要额外的服务治理组件，服务调用失败会涉及熔断降级的处理，需要熔断降级的组件。由于服务多，那么运维就需要更多，也就是说服务数量的增加，不仅是服务的增加，而是对于整个业务体系提出了更多的要求

由于服务的增多，服务之间的调用必然增多，那么服务之间网络调用会极大地增加系统的复杂度，为了解决复杂的网络调用，人们提出了服务网格的概念，服务网格将网络出错的解决方案从业务代码中剥离，沉淀到了边车中。

springcloud和Dubbo

1、dubbo由于是二进制的传输，占用带宽会更少

2、springCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大

3、dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决

4、springcloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级

5、dubbo的注册中心可以选择zk,redis等，springcloud的注册中心用eureka或者Consul

SpringCloud就像品牌机，整合在Spring大家庭中，Dubbo就像组装机，如果组件出现问题很不稳定