Spring Cloud 实现微服务系列以前言（一）

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

Spring Cloud

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

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

微服务

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

单体工程

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

单体有哪些问题

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

• 效率低

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

• 不灵活

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

• 稳定性差

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

• 扩展性不够

没法知足高并发下的业务需求

• 维护难

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

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

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

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

后端功能模块都已经拆分红不一样的服务， 对应的ip地址和端口均可能不一致， 如今客户端要先登陆，而后下单。这时候对应后端可能就是两个不一样服务，难道要客户端去记住这两个不一样的地址来调用吗， 若是客户端的操做涉及到十几个不一样服务呢？

2. 服务之间如何通讯

功能模块拆分红不一样服务后， 服务之间还须要互相调用， 好比， 下单时， 我要获取到下单的用户信息一块儿保存。这时下单服务就要去调用用户服务。这就是服务间的通讯问题。

3. 如何管理这些服务

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

4. 服务挂了怎么办

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

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

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

• 代码重复编写

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

• 服务调用链路长

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

• 部署工做量相对大

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

• 硬件需求高

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

微服务相关时间点

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

后续文章内容

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

文章合集地址

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