spring cloud 第 1 篇 微服务架构概述

微服务HOT？Why?

1. 微服务什么？
2. 微服务解决了什么问题？
3. 微服务有什么特点？

单体架构是什么

1. 一个归档包包含了应用所有功能的应用程序， 我们通常称之为单体应用。
2. 架构单体应用的架构风格， 我们称之为单体架构， 这是一种比较传统的架构风

单体架构存在的缺点  复杂性逐渐变高

1. 比如可能有120W代码，1万个函数
2. 技术债务逐渐上升

3. 人员的流动，可能前任会有坑，坑会越来越多。

4. 部署速度逐渐变慢

5. 代码越来越多，部署会越来越慢

6. 阻碍技术创新
7. 无法按需伸缩
8. 比如电影模块是cpu密集型的服务，订单模块是IO密集型的模块

   比如从struts到springMVC的技术的更改。

架构的演进（架构的目的是为了解决问题）

1. 单体架构
2. SOA
3. 微服务

什么是微服务

1. Martin Fowler：简而言之，微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
2. 来自：http://www.martinfowler.com/articles/microservices.html

微服务具备的特性

1. 1. 每个微服务可独立运行在自己的进程里；
2. 2. 一系列独立运行的微服务共同构建起了整个系统；
3. 3. 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理、用户管理等；
4. 4. 微服务之间通过一些轻量的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。

单体架构

微服务架构

微服务优点

1. 易于开发和维护

每个微服务，一般只关注一个业务的模块

1. 启动较快

每个微服务代码比较小啊

1. 局部修改容易部署

比如订单进行了修改，则只需要部署订单模块就可以啦

1. 技术栈不受限

比如，不同模块可以使用不同的语言和框架

1. 按需伸缩

比如订单模块是CPU密集型，电影模块是IO密集型

1. DevOps

便于开发

微服务带来的挑战

1. 运维要求较高

需要维护多个模块

1. 分布式的复杂性
2. 接口调整成本高

比如用户微服务发生变化了，而电影微服务调用他，那么电影微服务是不是也要变啊

1. 重复劳动

比如一般公共的utils啦，但是可以用maven统一管理。（前提统一的技术栈）

微服务设计原则

1. 单一职责原则

比如说，订单微服务只关心订单的，电影微服务只关心电影的，也就是高内聚低耦合啦

1. 服务自治原则

比如:订单微服务，应该有自己的一切。（比如，开发，运维，测试，库）

1. 轻量级通信原则

通信的协议应该轻量，应该跨语言的

1. 接口明确原则

进了避免一个服务的修改，对另一个服务的影响

git hub:   https://github.com/wangrui0

qq邮箱：[email protected]