从0开始构建一个微服务后端系统-01-微服务与Spring Cloud

微服务与Spring Cloud

什么是微服务

一切事物，都是从历史中来，最终也会消散在历史中

在说什么是微服务之前，我们先来看看后端系统的软件架构变迁历史

单体应用阶段

在这一时期，一个应用的所有功能代码都堆积在一起。随着业务的发展与项目的持续迭代，最终，这种项目将变得越来越臃肿。

总结起来，主要有以下几个缺点：

• 可靠性差

代码量越大，就越容易产生异常，很容易由于某个功能的异常，导致整个系统的崩溃

• 部署代价大

不管我们需要修改的功能是大是小，都需要对整个项目进行部署

开发、测试的时候也是，启动项目的时候，需要整个项目都启动，加载进所有的代码，势必导致今后启动越来越慢。

• 扩展性差

单体应用中，我们在开发新功能的时候，必须考虑到当前项目已有代码是否支持。

比如，在一个Spring项目中，已经上线的功能依赖了某个jar，而新要开发的功能，需要依赖的jar和已有jar是冲突的，那么就会增加我们的开发难度

• 代码管理困难

随着项目生命周期的增长，代码量的日益庞大，一旦没有严格的代码规范，或者执行起来的时候没那么严格，就会导致一个项目中的代码风格各异，后人想要理解旧代码逻辑，在其上修改或新增功能的难度越来越大。

---

单体应用的缺点不止上面几点，但归结起来，其缺点，都是由于代码都在一块，相互之间会有影响所导致的。

分布式系统与微服务

• 分布式系统

因为单体应用存在诸多缺点，于是乎，业界开始将代码拆开成多个应用进行部署。应用之间按照一定的协议进行通讯。

以上这一句话，基本上就已经把分布式系统的核心特征给概括出来了，但是对于没有接触过分布式系统开发的同学来说，可能并没有形成直观的认识。

这个也是没办法的，只能靠多写代码，多接触项目，才能形成自己的认识。

毕竟，纸上得来终觉浅，绝知此事要躬行。

分布式的优点，是由于服务拆分导致的；相对的，分布式的缺点/难点，也是由于其服务拆分所导致的。

生活中的事情也是如此，不是黑白对立，不是对错选择。我们接收了一个事物的好，同时也得承受导致这个好的特性所带来的坏。

先做个简单的说明吧，单体应用转向分布式后，会产生以下几个问题/关键字

1、服务间调用、服务治理

2、雪崩效应

3、服务降级

4、分布式事务

5、分布式锁

6、分布式主键id

7、多节点多服务的高效运维部署

8、CAP定理、BASE理论

• 微服务

首先，微服务不是和分布式对立的一个东西。

本质上，微服务系统一定是分布式系统。

微服务，是一种分布式系统的实践，有若干种原则和特性，但是很难用几句话准确的概括出什么样的系统就是微服务系统。

即使使用了Spring Cloud这种微服务框架的系统，也可能不是微服务系统。使用传统的SSM技术，也不代表就不是微服务系统。

从我自己的角度来看的话，微服务系统的核心特点就一个

就是 服务拆分

以一种或多种维度，对服务进行拆分，可以是技术上的，也可以是业务上的，这个独立出来的服务，其粒度大小的把握，往往是做微服务最难的点。怎么样让多个独立的服务协同作战完成具体的业务功能点，同时服务自身又保持一定的独立性，不依赖于其他服务，耦合性低。

其他的特点，网络上对于微服务的描述也有很多，我找了几个，大概有

服务组件化；
按业务组织团队；
智能端点与哑管道（服务调用方式，实时，异步中间件）
去中心化治理（组件能针对不同的业务特点选择不同的技术平台）
去中心化管理数据（多个不同的MySql实例，各服务之间进行“无事务”的调用，数据一致性，只要求数据在最后的处理状态是一致的即可。补偿机制）
基础设施自动化（自动化测试、自动化部署）
容错设计（快速检测出故障资源并尽可能地自动回复服务是必须被设计和考虑的）
演进式设计

这些特点，包括我说的核心特点，其实本质上都是对分布式系统的一种实践方案。

做个类比的话，就好像同样是用Java语言实现业务，不同人代码风格和代码组织结构可能是完全不同的，而这个不同，就是不同的实践。

什么是Spring Cloud

前面，我们对单体应用，微服务，做了简单的介绍，并没有涉及到具体的技术。

而Spring Cloud，就是对于微服务系统中要解决的问题，给出了一套解决方案。

如：服务治理、配置中心、链路追踪、网关路由等等