本文是SpringCloud系列文章的第一篇。
学习Springcloud要先理解微服务。明白SpringCloud是为了解决什么问题而产生的。
什么是微服务？微服务（Microservice Architecture）是近几年流行的一种架构思想，关于它的概念很难一言以蔽之。
此图适用于一切高大上的名字——技术有SOA，Agile，CLOUD，DevOps等等，古代有道，气，八卦等等。此类名词的最大特点就是：一解释就懂，一问就不知，一讨论就打架。
这个词的流行，要归功于 ThoughtWorks 公司的首席科学家 Martin Fowler 。这个人厉害在于，特别擅长抽象归纳和总结概念。
对微服务的官方解释，引用Fowler大叔的话：
In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
简而言之，微服务有一下几个特点：
-
将应用打散成一系列小服务，每个服务运行在独立的进程中。
-
相互之间通过轻量级的机制通信，通常来讲是rest服务。
-
服务是根据业务能力进行切分，并且可以自动化的进行独立的扩张部署。
-
整个服务的集中管理（就是服务注册与发现那一套）功能压缩到最小的限度，并且集中管理的模块可以用不同的语言和数据存储技术实现。
要理解微服务架构，采用对比法可以很好的说明
在刚工作的时候，我参与过多个B/S架构的业务应用的开发。
这些项目通常都是下面的简单结构。
各个业务模块的代码统一打包在一个war中，一起部署。
数据库通常也是同一个库。
这种架构称为Monolithic（暂且翻译为巨石架构）。像一块大石头一样，所有代码都堆在一起。
这种架构的优点很明显，适合小型项目，开发起来简单直接，工期较短。项目上线之后一般较少改动。
所以非常多的政府部门或者国企的外包项目都是这种架构开发的。
缺点和优点一样明显：
1，部署不灵活，一个小改动，就需要重新构建打包部署整个应用
2，扩展不方便。业务量突增情况下，难以水平扩展
3，代码维护困难。所有开发人员的代码维护在一起，相互依赖耦合。往往牵一发而动全身。
4，未定型不高。一个业务代码存在bug，可能导致真个应用宕机。
所以，为了应对这些问题。我们很自然的会想到，能不能每个模块启动一个进程，各个模块之间相互进行服务调用。很好，这就有了微服务的雏形：
这样一来，就会产生非常多的服务。服务的管理和路由要如何来做？
不可能让前端记住所有的后台服务，所以抽象出一层api网关，统一做接口的对外暴露和管理。
后台服务之间的发现与调用，抽象出一个注册中心模块。统一负责服务的路由发现，负载均衡，故障转移功能。
Dubbo中有基于zookeeper做的注册中心模块，Springcloud是有Eureka模块
总结：
微服务其实很简单，核心就是根据业务能力合适的切分服务，以及解决随着而来的服务发现、负载均衡及故障转移的一系列问题。
这套技术架构在微服务概念提出之前，在各大厂商内部已经在使用了。只是以前没有一个统一的概念模型。
微服务是随着业务的成长自然而然成长出来的。对于我们现在的创业公司，好处是可以在创业初期就使用微服务框架构建应用，提前应对业务成功后疯长的系统压力。而不需要再走一遍互联网大厂的路。这点上还是幸运的。
文章来源：
欢迎关注：Y叔的笔记
