微服务HOT？Why?
- 微服务什么？
- 微服务解决了什么问题？
- 微服务有什么特点？
单体架构是什么
- 一个归档包包含了应用所有功能的应用程序， 我们通常称之为单体应用。
- 架构单体应用的架构风格， 我们称之为单体架构， 这是一种比较传统的架构风
单体架构存在的缺点 复杂性逐渐变高
- 比如可能有120W代码，1万个函数
- 技术债务逐渐上升
- 人员的流动，可能前任会有坑，坑会越来越多。
- 部署速度逐渐变慢
- 代码越来越多，部署会越来越慢
- 阻碍技术创新
- 无法按需伸缩
- 比如电影模块是cpu密集型的服务，订单模块是IO密集型的模块 比如从struts到springMVC的技术的更改。
架构的演进（架构的目的是为了解决问题）
- 单体架构
- SOA
- 微服务
什么是微服务
- Martin Fowler：简而言之，微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
微服务具备的特性
- 1. 每个微服务可独立运行在自己的进程里；
- 2. 一系列独立运行的微服务共同构建起了整个系统；
- 3. 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理、用户管理等；
- 4. 微服务之间通过一些轻量的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。
单体架构
微服务架构
微服务优点
- 易于开发和维护
每个微服务，一般只关注一个业务的模块
- 启动较快
每个微服务代码比较小啊
- 局部修改容易部署
比如订单进行了修改，则只需要部署订单模块就可以啦
- 技术栈不受限
比如，不同模块可以使用不同的语言和框架
- 按需伸缩
比如订单模块是CPU密集型，电影模块是IO密集型
- DevOps
便于开发
微服务带来的挑战
- 运维要求较高
需要维护多个模块
- 分布式的复杂性
- 接口调整成本高
比如用户微服务发生变化了，而电影微服务调用他，那么电影微服务是不是也要变啊
- 重复劳动
比如一般公共的utils啦，但是可以用maven统一管理。（前提统一的技术栈）
微服务设计原则
- 单一职责原则
比如说，订单微服务只关心订单的，电影微服务只关心电影的，也就是高内聚低耦合啦
- 服务自治原则
比如:订单微服务，应该有自己的一切。（比如，开发，运维，测试，库）
- 轻量级通信原则
通信的协议应该轻量，应该跨语言的
- 接口明确原则
进了避免一个服务的修改，对另一个服务的影响
git hub: https://github.com/wangrui0
本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。
