springCloud 在国内小公司能启用起来吗？ 从2016 年初一到现在这条路上已经走了几年了。

在使用Spring Cloud 之前，我们队微服务实践没有太多的体会和经验的。从最初的开源软件云收藏来熟悉Spring boot，到项目中慢慢使用，再到最后全面拥抱SpringCloud。
这篇文章给大家来介绍我们使用 Spring boot /cloud 一年多的经验总结。
在开始之前我们先介绍几个概念，什么是微服务，他的特点是什么？ Springboot/cloud 都做了那些事情？ 他们三者间又有什么关系？

什么是微服务

微服务的概念源于2014年3月 Matrin Fowler 所写的一片文章"Microservices".文中内容提到： 微服务架构是一种架构模式，他提倡将单一应用程序划分成一组小的服务，服务之间相互协调，互相配合，为永不提供最终的价值。

每个为微服务在其独立的进程中，服务于服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的RESTFulAPI）。每个服务都围绕着具体的业务进行构建，并且被独立的部署到生产环境，类生产环境等、。

另外，应尽量避免统一的，集中式的服务管理机制，对具体的一个服务而言，应根据业务的上下文，选择合适的语言，工具对其进行构建。

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

微服务架构优势。

01 复杂度可控
再将应用分解的同时，规避了原本复杂度无止境的积累。每个微服务专注于单一功能，并通过定义良好的接口清晰的表示服务边界

由于体积小，复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性和开发效率。

02独立部署

由于微服务具备独立的运行进程，所以每个微服务也可以独立部署。当某个微服务发生变更时无需编译，部署整个应用。

由微服务组成的应用相当于具备一系列可并行的发布流程,使得发布更加高效，同时降低对生产环境所造成的风险，最终缩短对生产环境所造成的风险，最终缩短应用交付周期。

03 技术选型灵活
微服务架构下，技术选型是去中心化的，每个团队可以根据自身服务的需求和行业发展的现状，自由的选择最合适的技术栈。

由于每个未付都相对简单，所以需要技术栈进行升级时所面临的风险就比较低，甚至完全重构一个微服务也是可以的。

04 容错
当某一个组件发生故障时，在单一进程的传统架构下，故障很可能在进程内扩散，形成应用全局性的不可用。

在微服务架构下，故障会被隔离在单个服务中。若设计良好，其他服务可以通过重试，平稳退化等机制实现应用层面的容错。

05扩展

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

什么是springboot
springboot 是由Pivotal团队 提供的全新的框架，其涉及到目的是用来简化新Spring应用的初始搭建以及开发过程。该框架使用了特定的方式进行配置，从而使开发人员不需要定义样板化的配置。

用我化来了解，就是Spring boot 不是什么新的框架，它默认配置了很多框架的使用方式，就像maven 整合了所有的jar包，spring boot整合；了所有的框架（不知道这样比喻是否合适）

Spring boot 简化了基于Spring 的应用开发，通过少量的代码就能创建一个独立的，产品级别的spring应用。 Spring boot 为Spring 平台及第三方库提供开箱即用的设置，这样你就可以有条不紊的开始

spring boot 的核心思想就是约定大于配置，多数Springboot 应用只需少量的spring 配置。采用Springboot 可以大大简化你的开发模式，所有你想集成的常用框架，他都有对应的组件支持。

spring Cloud 都做了那些事？

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

以下为spring cloud 的核心功能：
分布式/版本华配置

服务注册和发现

路由

服务与服务之间的调用

负载均衡

断路器

分布式消息传递

我们再来看一张图：

65.png

解释下这张图中各组件的运行流程：

所有请求都统一通过API网关(Zuul)来访问

网关接到请求后，从注册中心(Eureka）获取可用服务。
由Ribbon进行负载均衡后，分发到后端的具体实例。

微服务之间通过feign进行通信处理业务

hystrix负责处理服务超时熔断

Turbine 监控服务间的调用和熔断相关指标

当然上面只是Spring Cloud 体系的一部分，Spring Cloud 工集成了19个子项目里面都包括一个或者多个第三方组件或者框架。
spring cloud 工具框架
spring cloud config 配置中心，利用git集中管理程序的配置
spring cloud Netflix 集成众多Netflix 的开源软件。
spring cloud bus，消息总栈，利用分布式消息将服务和服务实例链接在一起，用于在一个集群中传播状态的变化
spring cloud for cloud Foundry,利用prival Cloudfoundry 集成你的应用程序。
spring cloud Foundry service Broker, 为建立管理云拖管服务的服务代理提供了一个起点。
spring cloud foundry service Broker 为建立管理云托管服务的服务代理提供了一个起点。
Spring cloud Cluser,基于zookeeper,Redis,Hazelcast,Consul
实现的领导选举和平民状态下的抽象和实现。

Spring Cloud Consul ，基于hashicrop Consul 实现的服务发现和配置管理。

Spring cloud Security,在Zuul 代理中为OAuth2 rest客户端和认证头转发 提供 负载均衡。

1.jpg

spring Cloud Sleuth Spring Cloud 应用的分布式追踪系统和Zipkin,HTrace，ELK兼容

Spring Cloud Data Flow，一个云本地程序操作模型，组成数据微服务在一个结构化的平台上。

Spring Cloud Stream，基于 REdis，RabbIT，Kafka 实现的消息微服务，简单声明模型用以在spring cloud 应用中收发消息。

spring cloud Stream App Starts,基于 Springboot 为外部系统提供Spring 的集成。
Spring cloud Task，短生命周期的微服务，为Spring boot 应用简单申明添加功能和非功能特性。

Spring Cloud Task App Atarters.

Spring Cloud Zookeeper,服务发现和配置管理基于Apache Zookeeper.

Spring cloud for Amazon Web Services, 快速和亚马逊网络服务集成。

Spring cloud Connectors,便于 paas应用在各种平台上连接到后端像数据库和消息经济服务
Spring Cloud Starters,项目已经终止并且在Angel。SR2后的版本和其他的项目合并。

Spring Cloud CLI， 插件用Groovy快速的创建Spring Cloud 组件应用。
这个数量还一直在增加.................
三者之间的关系
微服务是一种架构的理念，提出了微服务的设计原则，从理论为具体的技术落地提供了指导思想。
Spring Boot 是一套快速配置脚手架，可以基于Spring boot快速开发单个微服务+。

Spring Cloud 是一个基于Spring boot 实现的服务治理工具包，Spring BOOT专注于快速，方便集成的单个微服务个体；
Spring Cloud关注全局的服务治理框架。

Spring Boot /Cloud 是微服务实践的最佳落地方案。

Spring Boot /Cloud 微服务实践背景。
2015年初的时候，因为公司业务大量发展，我们开始对原有的业务进行拆分，新上的业务线也全部使用独立的项目来开发，项目和项目之间通过http接口进行访问。
2015年的业务发展非常迅速，项目数量也相应的极具扩大，到了年底的时候项目达60多个，当项目达到30几个的时候，我们就遇到问题，经常为某个项目为扩展增加新的ip地址，就需要被动的更改好几个相关的项目。
服务越来越多，服务之间的调用关系也越来越复杂，有时候想画一个图来表示项目和项目之间的依赖关系，线条密密麻麻的无法看清，下面有个图可以表达我们的心情。

1.png

这个时候我们就想找一种方案，可以将我们这么多的分布式的服务给管理起来，到网上进行了技术调研我们发现与2款开源软件比较适合我们，一个是Dubbo,一个是spring Cloud.

刚开始我们走了一些弯路的，这2款框架我们都不熟悉，当时国内使用Spring Cloud进行开发的企业非常少，我在网上也几乎找不到太多应用的案例。但是Dubbo 在国内的使用还是比较普遍的，相关的各方面资料都比较完善。
因此在公司扩展新业务线 众筹平台的时候，技术选型就先订了Dubbo,也因为是全新的业务没什么负担，这个项目我们大概开发了6个月投产，上线之初也遇到了一些问题，但是最终还是比较顺利

在新业务选型使用Dubbo的 同时，我们也没有完全放弃Spring Cloud，我们抽出了2名开发人员学习Spring Boot,我也参与其中。

为了验证Springboot 是否可以到达实战的标准，我们在业余时间使用Spring boot 开发了一款开源的云收藏软件，经过这个项目的实战验证了我们对 Spring boot 的信心，

最重要的是大家体会到使用Spring boot的各种便利后，就在也不想使用传统的方式进行开发了。

但是还有一个问题，在选择了Spring boot进行业务开发的同时，并没有解决我们上面的那个问题，服务与服务直接调用任然比较复杂和传统，这个时候 我们就开始 研究Spring Cloud

因为之前大家对spring boot 有了足够的了解，因此学习Spring Cloud 就显得顺风顺水了。所以在使用Dubbo半年之后，我们又全面拥抱Spring Cloud

为什么选择使用Spring cloud 而放弃了Dubbo
可能大家会问，为什么选择了使用Dubbo之后，又全面使用SPring Cloud呢？ 其中有如下4个原因：

01 从2个公司的背景来谈：
Dubbo,是阿里巴巴服务化治理的核心框架，并被广泛的应用于中国各大互联网公司；Spring Cloud是大名鼎鼎的Spring 家族的成员

阿里巴巴是一个商业公司，虽然也开源了很多的顶级项目，但是从整体战略上来说，任然服务与自身的业务为主。

Spring 专注于企业级开源框架的研发，不论是在中国还是世界上使用都非常广泛，开发出，通用，开源，稳健的开源框架是他们的主业务。

02从社区活跃度对比，
Dubbo 虽然也是一个非常优秀的服务治理框架，并且在服务治理，灰度发布，流量分发这方面做得比spring cloud还好，除了当当网在此基础上增加的rest 支持外，已经有2年多时间就不没有任何更新

在使用中出现 问题，开发者提交到GitHub的Issue也少有回复。相反Spring cloud自从发展到现在，仍然在不断的告诉发展。

从gitHub上提交代码的频率和发布版本的时间间隔就可以看出，现在Spring Cloud 即将发布2.0版本，到了后期会更加完善和稳固。

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

04从技术发展的角度来讲

Dubbo 刚出来的那会技术理念还是蛮先进的，解决了企业各大互联公司服务治理的问题，中国各中小公司也从中收益不少。

受过这么多年的发展，互联网行业涌现了更多先进的技术和理念，Dubo一直停滞不前，自然有些掉队，有时候我个人也会有些惋惜，如果Dubo一直延当初的那个线路发展，并且延伸到周边，今天可能又会是另外一番景象了。

Spring 推出Spring boot /Cloud 也是因为自身的狠毒原因。 Spring最初推崇的是轻量级框架，随着不断的发展也越来越庞大，随着集成项目越来越多，配置文件也月累越混乱，慢慢的背离当初的理念。

随着这么多年的发展，微服务，分布式链路跟踪等更多新的技术理念的出现， spring 急需要一款框架来改善以前的开发模式，因此才出现了Spring boot /cloud 项目。

我们在访问Spring 官网，会出现Spring boot 和spring cloud 已经放在首页最重点突出的三个项目中的前2个，可见Spring 对这俩个框的重视程度。

因此Dubbo 确实很牛逼，但是Spring Cloud是站在近些年技术发展之上进行的开发，因此更具有技术代表性。

如何进行微服务架构演进

当我们将所有的新业务都使用Spring Cloud 这套架构后，就会出现这样一个现像：公司的系统被分成了2部分，一部分是传统架构的项目，另一部分是微服务架构的项目，如何让这俩套配合起来使用就成为了关键。

这时候spring Cloud里面的一个关键组件解决了这些问题，就是zuul。在spring cloud架构体系内的所有服务都通过Zuul来对外提供统一的访问入口，所有需要和微服务架构内部服务进行通讯的请求都走统一开关，如下图：

15595524-01f208f1f243efcc.png

从上图可以看出我们对服务进行了4中分类，不同的服务迁移的优先级不同：

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

业务服务，是一些垂直的业务系统，只处理单一的业务类型，比如： 风控系统，积分系统，合同系统。

这类服务职责比较单一，根据业务情况来选择是否迁移，比如： 如果突然有需求对积分系统进行大优化，我们就趁机将积分系统进行改造，使我们的第二优先级分离出来的服务。

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

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

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

架构演变的步骤如下：
在确定使用Spring Boot、cloud 这套技术栈进行微服务改造之前，请先梳理平台的服务，对不同的服务进行分类，一确认演化的节奏。

先让团队熟悉Spring boot技术，并且优先早基础服务上进行技术改造，推动改动后的项目投产上线。

当团队熟悉spring boot技术后，在推进使用Spring Cloud 对原有的项目进行改造。

在进行微服务改造过程中，优先应用于新业务系统，前期可以只是少量的项目进行微服务改造，隋钊大家对技术的熟悉度增加，可以加大微服务改造的范围。
出啊通项目和微服务项目共存是一个很常见的情况，除非公司业务有大的变化，不建议直接迁移核心项目。

服务拆分：
服务拆分的2个原则：
横向拆分，按照不同的业务域进行拆分，例如，订单，营销，风控，积分资源等，形成独立的业务域或微服务集群。

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

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

服务拆分是越小越好吗？ 微服务的大与小是相对的。比如在初期，我们把交易拆分为一个微服务，但是随着业务量的增大，可能一个业务系统已经慢慢变得很大，并且并发流量也不小。

为了支撑更多的交易量，我们会把交易系统，拆分为订单系统，投标服务，转让服务等。因此微服务的拆分力度域具体的业务相结合，总的原则是服务内部，高内聚，服务之间低耦合。

微服务vs传统开发。

使用服务有一段时间了，这种开发模式和传统的开发模式相对，有很大的不同。。有如下几点：

分工不同，以前我们可能是一个一个模块，现在可能是一人一个系统。
架构不同，服务的拆分是一个技术含量很高的问题，拆分是否合理第一以后的发展影响巨大。

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

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

给数据带来挑战：

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

有如下三种方案：

严格按照微服务的划分来做，微服务相互独立，各微服务数据库也独立，后台需要展示数据时，调用微服务的接口来获取对应的数据，在进行数据处理后台展示出来，这是标准的用法，也是最麻烦的用法。
将业务相关的表放到一个库中，将业务无关的表严格按照微服务模式来拆分，这样既可以使用微服务，也避免了数据库各种切换导致后台无法统计那一实现，是一个折中的方案。

数据库严格按照微服务的要求来拆分，以满足业务高并发，事实或者准时将各种微服务数据库同步到NoSql数据库中，在同步带过程中进行数据清洗，用力啊满足后台业务系统的应用，推荐使用Mongodb,Hbase 等、

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

微服务的经验和建议
01建议尽量不要用jsp ,页面开发推荐使用Thymeleaf

Web 项目 建议独立部署Tomcat,不要使用内嵌的Tomact,内嵌的Tomcat部署Jsp 项目会偶先龟速访问的问题。

02 服务编排是个好东西，主要作用是减少项目中的相互依赖

比如现在有项目a 调用调用项目b， 项目b 调用项目c.,.. 一直到h，是一个调用链，那么项目上线的时候需要更新最底层的h,在更新c更新 b...
这只是一个调用链，在复杂的业务中有非常多的调用，如果要记住每一个调用链对开发，运维人员来说就是一个灾难

有个好的办法可以尽量的减少项目之间的相互依赖，就是服务编排，一个核心的业务处理项目，负责和各个微服务打交道。

比如之前是a 调用b ,b在调用c, c在调用d ,现在统一在一个核心项目w中来处理，w服务使用a 调用b时，使用b的时候w去调用c

举个例子： 在第三方支付业务中，有一个核心支付项目是服务编排，负责处理支付的业务逻辑，w项目使用商户信息的时候就会调用"商户系统" ,需要检验设备时候用 :"终端系统"，需要风控的时候就会调用"风控系统" ,各个项目需要的依赖参数都由w来做主控，以后项目部署的时候，只需要最后启动服务编排项目既可。

03不要为了追求技术而追求技术

需要考虑以下方面的因素

团队的技术人员是否已经具备相关技术基础。

公司业务是否适合进行微服务改造，并不是所有的平台都适合进行微服务改造，比如：传统行业有很多复杂垂直的业务系统。
spring cloud 生态技术有很多，并不是每一个技术方案都需要用上，适合自己的才是最好的。

总结：
spring cloud 对于中小型互联网公司来说是一种福音，因为这类公司没有实力或者没有足够的资金投入去开发自己的分布式基础设施，使用spring cloud一站式解决方案能从容的应对业务发展的同时大大的减少开发资本

同时，随着近几年微服务架构和Docker容器概念的火爆，也会让Spring cloud 在未来越来越“云” 化的软件开发风格中立有一席之地。

尤其是在目前五花八门的分布式解决方案中提供了标准化的，全站式的技术方案，意义可能堪比当前 Servlet 规范的诞生，有效推进服务端软件系统技术水平的进步。

1.png 2.png