为什么我选择了 SPRING CLOUD 分布式 微服务

公司重构系统的时候我选择了spring-cloud的微服务模式替代SpringMVC进行代码改造。在使用的一年半中磕磕绊绊遇到问题解决问题，但瑕不掩瑜，spring-cloud改变了以往的运作方式，无论从运维还是代码开发都大大节约了人力成本。

现在跟大家分享下我为什么选择spring-cloud，对比以往传统架构他的优点是什么。理解不足或描述错误的地方还请斧正。

顺便说一句，欢迎转载~请标明出处。

常见的架构

单体架构

单体架构在小微企业比较常见，一个应用、一个数据库、一个web容器就可以跑起来。

在两种情况下可能会选择单体架构：

一、在企业发展的初期，为了保证快速上线，采用此种方案较为简单灵活；

二、传统企业中垂直度较高，访问压力较小的业务。在这种模式下对技术要求较低，方便各层次开发人员接手，也能满足客户需求。 

单体架构的架构图： 

在单体架构中，技术选型非常灵活，优先满足快速上线的要求，也便于快速跟进市场。 

垂直架构

在单体架构发展一段时间后，公司的业务模式得到了认可，交易量也慢慢的大起来。这时候为了应对更大的访问流量，就会对原有的业务进行拆分，比如说：后台系统、前端系统、鉴权系统和业务系统等。

在这一阶段往往会将系统分为不同的层级，每个层级有对应的职责。UI层负责和用户进行交互、业务逻辑层负责具体的业务功能、数据库层负责和上层进行数据交换和存储。比如我们开发的资产盘活和资产验收就是垂直架构的系统。

垂直架构的架构图：

在这个阶段SSM（SpringMVC、Spring、MyBatis）是项目的关键技术，SpringMVC负责逻辑控制、Spring负责业务层管理Bean、MyBatis负责数据库操作进行封装，持久化数据。 

服务化架构SOA

如果公司进一步的做大，垂直子系统会变的越来越多，系统和系统之间的调用关系呈指数上升。在这样的背景下很多公司都会考虑服务SOA化。

SOA代表面向服务的架构，将应用程序根据不同的职责划分为不同的模块，不同的模块直接通过特定的协议和接口进行交互。

整个系统切分成很多单个组件服务来完成请求，当流量过大时通过水平扩展相应的组件来支撑，所有的组件通过交互来满足整体的业务需求。优点是可以根据需求通过网络对应用组件进行分布式部署、组合和使用。服务化架构是一套松耦合的架构，服务的拆分原则是服务内部高内聚，服务之间低耦合。 

服务化架构图：

SOA的隐性缺陷

当集中式应用转变成分布式系统后，系统之间的相互可靠调用一直以来都是分布式架构的难题。

网络通信，序列化协议设计等很多技术细节需要确定。

一个高性能的框架，能够构建高可用的分布式系统，系统地考虑各个应用之间的分布式服务发现、服务路由、服务调用以及服务安全等细节。

对比SOA和微服务架构

服务化架构已经可以解决大部分企业的需求了，为什么要研究微服务？

微服务架构强调：

业务系统需要彻底的组件化和服务化，一个组件就是一个产品，可以独立对外提供服务。

不再强调传统SOA架构里面比较重的ESB企业服务总线。

强调每个微服务都有自己独立的运行空间，包括数据库资源。

源于互联网的思路，服务强调了采用HTTP Rest API的方式来进行

切分粒度会更小

微服务架构是 SOA 架构思想的一种扩展，更加强调服务个体的独立性、拆分粒度更小。

微服务架构关键词

有新的应用上线应该怎么办？

应用是运维管理的基本单位

完整的应用生命周期管理机制应该包括：

1、应用创建 2、部署 3、启动 4、回滚 5、扩容缩容 6、停止下线等。

我们需要服务注册和发现

服务中心将所有的可以提供的服务都注册到它这里来管理，其它各调用者需要的时候去注册中心获取，然后再进行调用，避免了服务之间的直接调用，方便后续的水平扩展、故障转移等。

随着系统的流量不断增加，需要根据情况来扩展某个服务，只需要增加相应的服务端实例既可。

在系统的运行期间服务中心有一个心跳检测机制，如果某实例在规定的时间内没有进行通讯则会自动被剔除掉，避免了某个实例挂掉影响服务。从而实现了注册、负载均衡、故障转移的功能。

多应用如何相互访问才能保证安全？

一个好的服务框架要保证用户每一次分布式调用的稳定与安全。在服务注册、服务订阅以及服务调用等每一个环节，都需要进行严格的服务鉴权。

我们需要服务网关 

网关提供了动态路由，监控，弹性，安全等的边缘服务。它的具体作用就是服务转发，接收并转发所有内外部的客户端调用。作为资源的统一访问入口，同时也可以做权限校验等类似的功能。

不同的服务一般有不同的网络地址，而外部的客户端可能需要调用多个服务的接口才能完成一个业务需求。

以资产盘活数据统计为例,可能会调用以下几个服务：

用户微服务  资产分类微服务  订单微服务等

如果客户端直接和微服务进行通信，会存在以下问题：

客户端会多次请求不同服务，增加复杂性。

存在跨域请求，处理复杂。

每一个服务都需要独立认证认。

代码难以重构。

上述问题，都可以借助网关解决。微服务网管是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过微服务网关。

应用如何高效管控，服务又如何治理？

服务降级

流量管控

我们需要熔断器

服务雪崩效应：一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。

熔断器在某个服务连续调用N次不响应的情况下，立即通知调用端调用失败，避免调用端持续等待而影响了整体服务。间隔一段时间后再次检查此服务，如果服务恢复将继续提供服务。

不适用场景

核心无降级业务:拍照验收时验收照片是业务核心，这时如果拍照服务无法使用整个资产验收服务就应该终止。

适用场景

边缘业务或者可降级的业务:同样是拍照，在资产盘活中上架物品对照片的需求没有非常强烈，这时如果拍照服务出现问题，不应该影响资产上架，就可以利用熔断器来保证上架流程正常进行。

运维如何高效定位问题？

随着服越来越多，对调用链的分析会越来越复杂。服务之间的调用关系、某个请求对应的调用链、调用之间消费的时间等，对这些信息进行监控就成为一个问题。

在实际的使用中我们需要监控服务和服务之间通讯的各项指标，这些数据将是我们改进系统架构的主要依据。因此分布式的业务流程跟踪就变的非常重要。

我们需要链路跟踪

通过链路追踪可以很清楚的了解到一个服务请求经过了哪些服务，每个服务处理花费了多长时间。从而让我们可以很方便的理清各微服务间的调用关系。

微服务的技术栈

Eureka进行服务注册发现，连接微服务

Hystrix监控服务调用进行熔断保护

Config提供了统一的配置中心服务

所有对外的请求和服务都通过Zuul来进行转发，起到API网关的作用

使用Sleuth、Zipkin将所有的请求数据记录下来，进行后续分析

这些功能都是以插拔的形式提供出来，方便我们系统架构演进的过程中，可以合理的选择需要的组件进行集成，从而在架构衍进的过程中会更加平滑顺利。

我们可以获得什么？

硬件部署架构