随着互联网的发展，网站应用的规模不断扩大。需求的激增，带来的是技术上的压力。系统架构也因此也不断的演进、升级、迭代。从单一应用，到垂直拆分，到分布式服务，到SOA，以及现在火热的微服务架构，还有在Google带领下来势汹涌的Service Mesh。我们今天看一看系统架构演变的历程，重点学习SpringCloud。

1.系统架构演变

集中式架构

    当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。

    存在的问题：

• 代码耦合，开发维护困难

• 无法针对不同模块进行针对性优化

• 无法水平扩展

• 单点容错率低，并发能力差

垂直拆分

    当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能对系统进行拆分。

优点：

• 系统拆分实现了流量分担，解决了并发问题

• 可以针对不同模块进行优化

• 方便水平扩展，负载均衡，容错率提高

缺点：

• 系统间相互独立，会有很多重复开发工作，影响开发效率

分布式服务

    当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调用是关键。

优点：

• 将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率

缺点：

• 系统间耦合度变高，调用关系错综复杂，难以维护

服务治理（SOA）

    当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。

优点：

• 服务自动订阅，服务列表自动推送，服务调用透明化，无需关心依赖关系

• 动态监控服务状态监控报告，人为控制服务状态

缺点：

• 服务间会有依赖关系，一旦某个环节出错会影响较大

• 服务关系复杂，运维、测试部署困难，不符合DevOps思想

微服务

微服务的特点：

• 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责

• 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”。

• 面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可。

• 自治：自治是说服务间互相独立，互不干扰

• 团队独立：每个服务都是一个独立的开发团队，人数不能过多。

• 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉

• 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口

• 数据库分离：每个服务都使用自己的数据源

• 部署独立，服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

2.初识SpringCloud 

    微服务是一种架构方式，最终肯定需要技术架构去实施。微服务的实现方式很多，但是最火的莫过于Spring Cloud了。作为Spring家族的一员，有整个Spring全家桶作为靠山，背景十分强大。Spring作为Java领域的前辈，有强力的技术团队支撑。大多数程序员的成长都伴随着Spring框架，SpringCloud与Spring的各个框架无缝整合。SpringCloud完全支持SpringBoot的开发，用很少的配置就能完成微服务框架的搭建。

    SpringCloud也是一样，它将现在非常流行的一些技术整合到一起，实现了诸如：配置管理，服务发现，智能路由，负载均衡，熔断器，控制总线，集群状态等等功能。其主要涉及的组件包括：

• Netflix Eureka：注册中心（服务发现）

• Netflix Zuul：服务网关

• Netflix Ribbon：负载均衡

• Netflix Feign：服务调用

• Netflix Hystix：熔断器

Eureka注册中心

    Eureka服务端用作服务注册中心。支持集群部署。Eureka客户端是一个java客户端，用来处理服务注册与发现。在应用启动时，Eureka客户端向服务端注册自己的服务信息，同时将服务端的服务信息缓存到本地。客户端会和服务端周期性的进行心跳交互，以更新服务租约和服务信息。

Eureka架构中的三个核心角色：

• 服务注册中心

  Eureka的服务端应用，提供服务注册和发现功能，就是刚刚我们建立的eureka-demo

• 服务提供者

  提供服务的应用，可以是SpringBoot应用，也可以是其它任意技术实现，只要对外提供的是Rest风格服务即可。本例中就是我们实现的user-service-demo

• 服务消费者

  消费应用从注册中心获取服务列表，从而得知每个服务方的信息，知道去哪里调用服务方。本例中就是我们实现的consumer-demo

负载均衡Ribbon

    Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。

熔断器Hystrix

    为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的原因，服务并不能保证100%可用，如果单个服务出现问题，调用这个服务就会出现线程阻塞，此时若有大量的请求涌入，Servlet容器的线程资源会被消耗完毕，导致服务瘫痪。服务与服务之间的依赖性，故障会传播，会对整个微服务系统造成灾难性的严重后果，这就是服务故障的“雪崩”效应。

    Hystrix使用自己的线程池，这样和主应用服务器线程池隔离，如果调用话费很长时间，会停止调用，不同的命令或命令组能够被配置使用他们各自的线程池，可以隔离不同的服务。

Feign

    Feign可以把Rest的请求进行隐藏，伪装成类似SpringMVC的Controller一样。你不用再自己拼接url，拼接参数等等操作，一切都交给Feign去做。Feign支持多种注解，例如Feign自带的注解或者JAX-RS注解等。SpringCould对Feign进行了增强，是feign支持了Spring MVC注解，并整合了Ribbon和Eureka，从而让Feign的使用更加方便。

Zuul网关

    我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现；而服务间通过Ribbon或Feign实现服务的消费以及均衡负载；通过Spring Cloud Config实现了应用多环境的外部化配置以及版本管理。为了使得服务集群更为健壮，使用Hystrix的熔断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。

    当使用这样的架构，为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特点。从具体开发和测试的角度来说，在工作中除了要考虑实际的业务逻辑之外，还需要额外考虑对接口访问的控制处理。当我们需要对一个现有的集群内访问接口，实现外部服务访问时，我们不得不通过在原有接口上增加校验逻辑，或增加一个代理调用来实现权限控制，无法直接复用原有的接口。

       为了解决以上问题，我们需要将权限控制这样的东西从我们的服务单元中抽离出去，而最适合这些逻辑的地方就是处于对外访问最前端的地方，我们需要一个更强大一些的均衡负载器的服务网关。

    服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。

    Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。