springcloud是分布式框架吗_拥抱Spring Cloud微服务架构实践中的经验与总结

拥抱Spring Cloud微服务架构实践中的经验与总结

一、背景

大家都知道，微服务这个名词从2014年就开始流行出来了。期间出现了以国内阿里系为代表的Dubbo架构RPC模式的微服务架构，以Spring生态圈出现的Spring Cloud技术还处于萌芽阶段。

笔者2015年，所在的公司就开始使用Dubbo了，采用Zookeeper作为注册中心，服务提供者、服务消费者负载均衡等等。这套框架使用了一段时间，当时Dubbo在国内很火，几乎所有的互联网公司采用微服务都使用Dubbo。本来Dubbo拥有良好的天地的，可随着阿里暂停对Dubbo的更新维护，此时Spring Cloud逐渐出现了朝气蓬勃的发展，一些公司的技术栈转而拥抱Spring Cloud。

笔者2018年加入一家公司，就面临着是否采用Spring Cloud这套技术走下去，因为中小企业能否玩转Spring Cloud，我们还不确定。

二、技术调研

微服务是这样一个结构吗？前端或业务部门 - > ng集群 -> zuul集群 -> eureka-server集群 -> service provider集群。

想要明白这个问题，首先需要知道什么是Spring Boot，什么是Spring Cloud，如何利用好他们。

三、技术简介

3.1 Spring Boot

Spring Boot简化了基于Spring的应用开发，通过少量的代码就能创建一个独立的、产品级别的Spring应用。 Spring Boot为Spring平台及第三方库提供开箱即用的设置，这样你就可以有条不紊地开始。多数Spring Boot应用只需要很少的Spring配置。该框架使用了特定的方式来进行配置，从而使开发人员不再需要定义样板化的配置。Spring Boot整合了所有的框架。

3.2 Spring Cloud

首先，尽管Spring Cloud带有“Cloud”这个单词，但它并不是云计算解决方案，而是在Spring Boot基础之上构建的，用于快速构建分布式系统的通用模式的工具集。

　　 其次，使用Spring Cloud开发的应用程序非常适合在Docker和PaaS(比如Pivotal Cloud Foundry)上部署，所以又叫做云原生应用(Cloud Native Application)。云原生可以简单地理解为面向云环境的软件架构。

Spring Cloud是一个基于Spring Boot实现的云原生应用开发工具，它为基于JVM的云原生应用开发中涉及的配置管理、服务发现、熔断器、智能路由、微代理、控制总线、分布式会话和集群状态管理等操作提供了一种简单的开发方式。

Spring Cloud具有如下特点：

(1)约定大于配置

(2)适用于各种环境

(3)隐藏了组件的复杂性，并提供声明式、无XML式的配置方式

(4)开箱即用，快速启动

(5)组件丰富，功能齐全

......

　　Spring Cloud作为第二代微服务的代表性框架，已经在国内众多大中小型的公司有实际应用案例。

3.3 Spring Cloud与Spring Boot的关系

Spring Boot 是 Spring 的一套快速配置脚手架，可以基于Spring Boot 快速开发单个微服务，Spring Cloud是一个基于Spring Boot实现的云应用开发工具；Spring Boot专注于快速、方便集成的单个微服务个体，Spring Cloud关注全局的服务治理框架；Spring Boot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring Boot来实现，可以不基于Spring Boot吗？不可以。

Spring Boot可以离开Spring Cloud独立使用开发项目，但是Spring Cloud离不开Spring Boot，属于依赖的关系。

四、微服务

微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP的RESTful API)。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

4.1 微服务架构优势

复杂度可控：在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。

独立部署：由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译、部署整个应用。由微服务组成的应用相当于具备一系列可并行的发布流程，使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短应用交付周期。

技术选型灵活：微服务架构下，技术选型是去中心化的。每个团队可以根据自身服务的需求和行业发展的现状，自由选择最适合的技术栈。由于每个微服务相对简单，故需要对技术栈进行升级时所面临的风险就较低，甚至完全重构一个微服务也是可行的。

容错：当某一组件发生故障时，在单一进程的传统架构下，故障很有可能在进程内扩散，形成应用全局性的不可用。在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可通过重试、平稳退化等机制实现应用层面的容错。

扩展：单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点。当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展。

Spring Cloud架构图:

微服务落地案例:

4.2 Spring Cloud体系介绍

常用的5大组件

服务发现——Netflix Eureka

客服端负载均衡——Netflix Ribbon

断路器——Netflix Hystrix

服务网关——Netflix Zuul

分布式配置——Spring Cloud Config

五、实战经历

在开发互联网教育软件的过程中，我们面临着技术选型，到底是采用Dubbo微服务框架，还是采用Spring Cloud微服务框架。我们进行了一个月的研究，决定放弃Dubbo，拥抱Spring Cloud。

5.1 为何使用Spring Cloud

为什么选择了使用Dubbo之后，而又选择全面使用Spring Cloud呢？其中有几个原因：

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是站在近些年技术发展之上进行开发，因此更具技术代表性。

5.2 我们的微服务系统架构

我们对服务进行了分类，有四种：基础服务、业务服务、组合服务、前置服务。不同服务迁移的优先级不同:

(1)基础服务，是一些基础组件，与具体的业务无关。比如：短信服务、微信服务。这里的服务最容易摘出来做微服务，也是我们第一优先级分离出来的服务。

(2)业务服务，是一些垂直的业务系统，只处理单一的业务类型，比如：教育系统、公寓系统、宿管系统。这类服务职责比较单一，根据业务情况来选择是否迁移，比如：如果突然有需求对宿管系统进行大优化，我们就趁机将宿管系统进行改造，是我们的第二优先级分离出来的服务。

(3)前置服务，前置服务一般为服务的接入或者输出服务，比如网站的前端服务、app的服务接口这类，这是我们第三优先级分离出来的服务。

(4)组合服务，组合服务就是涉及到了具体的业务，比如买标过程，需要调用很多垂直的业务服务，这类的服务我们一般放到最后再进行微服务化架构来改造，因为这类服务最为复杂，除非涉及到大的业务逻辑变更，我们是不会轻易进行迁移。

在这四类服务之外，新上线的业务全部使用Sprng Boot/Cloud这套技术栈。

我们开发的绝大部分教育软件都采用这套架构。

六、经验和教训

6.1 服务拆分原则

横向拆分。按照不同的业务域进行拆分，例如订单、教室、学校、公寓等。形成独立的业务领域微服务集群。

纵向拆分。把一个业务功能里的不同模块或者组件进行拆分。例如把公共组件拆分成独立的原子服务，下沉到底层，形成相对独立的原子服务层。这样一纵一横，就可以实现业务的服务化拆分。

要做好微服务的分层：梳理和抽取核心应用、公共应用，作为独立的服务下沉到核心和公共能力层，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求

6.2 微服务与传统服务

使用微服务有一段时间了，这种开发模式和传统的开发模式对比，有很大的不同:

(1)分工不同，以前我们可能是一个一个模块，现在可能是一人一个系统。

(2)架构不同，服务的拆分是一个技术含量很高的问题，拆分是否合理对以后发展影响巨大。

(3)部署方式不同，如果还像以前一样部署估计累死了，自动化运维不可不上。

(4)容灾不同，好的微服务可以隔离故障避免服务整体down掉，坏的微服务设计仍然可以因为一个子服务出现问题导致连锁反应。

6.3 给数据库带来的挑战

每个微服务都有自己独立的数据库，那么后台管理的联合查询怎么处理？这应该是大家会普遍遇到的一个问题，有三种处理方案。

1)严格按照微服务的划分来做，微服务相互独立，各微服务数据库也独立，后台需要展示数据时，调用各微服务的接口来获取对应的数据，再进行数据处理后展示出来，这是标准的用法，也是最麻烦的用法。

2) 将业务高度相关的表放到一个库中，将业务关系不是很紧密的表严格按照微服务模式来拆分，这样既可以使用微服务，也避免了数据库分散导致后台系统统计功能难以实现，是一个折中的方案。

3)数据库严格按照微服务的要求来切分，以满足业务高并发，实时或者准实时将各微服务数据库数据同步到NoSQL数据库中，在同步的过程中进行数据清洗，用来满足后台业务系统的使用，推荐使用MongoDB、HBase等。

三种方案在不同的公司我都使用过，第一种方案适合业务较为简单的小公司；第二种方案，适合在原有系统之上，慢慢演化为微服务架构的公司；第三种适合大型高并发的互联网公司。

七、总结

在使用微服务的过程中，我们尝到了甜头，也希望能以Spring Cloud为依托，更好地面向未来。