这是Spring Cloud实现微服务系列文章的第一篇。打算先把相关概念、文章的后续内容及文章风格等介绍一下。

Spring Cloud

标题讲到两个概念， 第一个是Spring Cloud。那就先来说下它。

Spring Cloud是一个微服务框架， 或者说是一套微服务生态。总而言之， 它为微服务的开发提供了便利。

微服务

那Spring Cloud 是用来开发微服务工程的， 那什么叫做微服务工程?

单体工程

和微服务相对的是单体应用， 通过对比来了解什么是微服务。单体应用指的是， 整个应用只有一个服务。所有的功能模块、都放在一个项目里面。随着功能越来越来， 问题也慢慢的暴露出来， 微服务的出现就是为了解决单体开发产生的一些问题。微服务把不同的功能模块拆分成不同的服务。

单体有哪些问题

微服务解决了单体开发的一些问题， 那具体是哪些问题

• 效率低

开发都在同一个项目改代码，相互等待，冲突不断

• 不灵活

构建时间长，任何小修改都要重构整个项目，耗时

• 稳定性差

一个微小的问题，都可能导致整个应用挂掉

• 扩展性不够

无法满足高并发下的业务需求

• 维护难

代码功功能耦合在一起，新人不知道何从下手

要应用微服务开发需要解决的问题

要使用微服务开发， 需要解决以下问题， 才能应用

1. 如此多的服务， 客户端如何访问?

后端功能模块都已经拆分成不同的服务， 对应的ip地址和端口都可能不一致， 现在客户端要先登录，然后下单。这时候对应后端可能就是两个不同服务，难道要客户端去记住这两个不同的地址来调用吗， 如果客户端的操作涉及到十几个不同服务呢？

2. 服务之间如何通信

功能模块拆分成不同服务后， 服务之间还需要互相调用， 比如， 下单时， 我要获取到下单的用户信息一起保存。这时下单服务就要去调用用户服务。这就是服务间的通信问题。

3. 如何管理这些服务

服务这么多， 需要对每个服务的状态进行监控。和服务间的调用链查看等。

4. 服务挂了怎么办

单体开发方式一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，不过如果没有特别的保障，结局肯定是噩梦。所以当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：

• 重试机制
• 限流
• 熔断机制
• 负载均衡
• 降级（本地缓存）

微服务开发还存在哪些问题

• 代码重复编写

比如shiro拦截进行登录鉴权，在每个服务中都得单独写一份。

• 服务调用链路长

服务之间相互调用， 调用消耗大

• 部署工作量相对大

对于运维人员来说， 部署一个微服务开发的应用了， 需要部署和维护的服务多。

• 硬件需求高

一句话，在微服务开发的方式中， 内存是不值钱的。

微服务相关时间点

微服务这个概念是 2012 年出现的，作为加快 Web 和移动应用程序开发进程的一种方法，2014 年开始受到各方的关注，同年为微服务的元年。

后续文章内容

微服务需要解决上述提出的问题，才能得以应用。Spring Cloud 这套生态已经给我们提供了解决方案。接下来就是对Spring Cloud提供的微服务核心组件进行学习。感兴趣的同学可以先关注一下。

文章合集地址

发布的文章有些多， 整理出来一份目录大纲及文章说明。点这里查看