使用 Spring Cloud 搭建微服务项目架构

前言：

    本文为使用 Spring Cloud 搭建微服务项目架构的总体思路讲述，欢迎讨论。文章对新手不友好，推荐新手访问此文：史上最简单的 SpringCloud 教程 | 终章，讲得很好。

一、微服务的定义

    微服务的通俗定义就是一个小型的项目服务，可是写文章则须要有明确的定义才行。文绉绉的描述语言大概以下：

一个可以独立运行的、可提供完整服务的微型服务。

    这里面是三个条件：独立运行、可提供完整服务、微型。

    独立运行则意味着跟其余服务彻底解耦，若是服务之间存在业务关联，要么把他们合并为一个微服务，要么经过接口进行交互。这也意味着，不一样微服务之间若是涉及到数据库操做的话，一个微服务不能够直接操做属于另外一个微服务的库表，即便他们的表放在同一个库。由于这种行为一旦发生，那么这两个微服务又出现了新的耦合维度。

    可提供完整服务则意味着其余与之无关的微服务即便挂掉，它本身经过接口提供的服务也不受任何影响，除非他们之间存在接口互动上的关联，那样也只影响到有关联的部分。

    微型则表示每一个微服务都不会有太多的接口，不然就变成了传统的项目了。

    任何知足以上三个条件的服务，我都认为是一个微服务了——因此，微服务是一个概念，而不是一种技术。无论使用何种技术、何种框架、何种方式进行搭建。

二、微服务的好处

    微服务的好处主要有：敏捷开发、选择性扩容等

    使用微服务架构的项目，由于微服务之间彻底解耦，因此可实现敏捷开发——即某个微服务fix了某些BUG或者升级了版本，只须要从新部署升级便可，不须要像传统的项目同样，fix一个小BUG都要将整个服务从新部署升级；服务间的解耦，很是方便敏捷开发、升级等。

    同时也能够根据微服务的并发量进行选择性扩容或集群等，好比某个并发量极高的微服务，能够单独部署项目、数据库（上文提到微服务不能操做属于其余微服务的数据，即便是查询也不容许。这样，当某个微服务须要独立部署时，就不存在任何耦合带来的问题，不然就会致使其余微服务直接操做本微服务数据库由于迁移而失效的问题）等。

三、为何要用 Spring Cloud

    Spring Cloud 推荐了不少微服务的解决方案，使用 Spring Cloud 可快速搭建微服务架构，而且背靠 Spring 社区的良好生态。

四、使用 Spring Cloud 搭建微服务的思路

    首先须要一个注册服务的注册中心，可选择 zookeeper、eureka。

    其余的微服务都在本身搭建的注册中心注册，经过 resttemplate+ribbon 进行通讯，这时url不须要使用完整的 ip+port 的方式，而是使用微服务在注册中心注册时提供的名称便可。只用注册名而非 ip+port 的方式进行通讯还有一个好处，就是能够实现集群：同一个微服务部署多份，无论 ip 和 port 是什么，ribbon 都会调度微服务的集群，起到负载均衡的效果。

    还有使用 feign 可达到类RPC的接口调用效果，feign 自己已经使用了 ribbon。

    微服务提供接口给外部访问时，不能像微服务间通讯同样使用注册名通讯那么方便，仍是须要 ip+port 才能访问到：这样对接口使用方来讲是很是麻烦的，毕竟微服务的数量可能会很是多，外部调用方就要记住各个微服务的端口号等，并且这样就不能让集群生效了。这时可经过配置统一网关，让使用方经过网关再转发到对应的微服务便可。这样，多个微服务及集群的状况，对于调用方来讲都是透明的，用户的感知就是调用了服务的某个接口，而不是特定的某个微服务下的接口。

    统一网关可以使用zuul来配置。

这样，就基本完成了一个微服务的搭建，不使用框架的话，搭建微服务须要解决的问题颇多，不建议本身造轮子。