微服务的理解

为什么我们需要微服务？它能给企业带来什么价值

背景

传统企业的IT软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高.

SOA的软件架构专门针对这些问题给出了一套解决方案.
由于SOA早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终SOA开起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。

微服务

微服务，从本质意义上看，还是SOA架构。
但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有Java编写的服务，也可以有 Python 编写的服务，他们是靠Restful架构风格统一成一个系统的。

基于这种简单的的协议规范，无论是兼容老旧系统，还是上线新业务，都可以随着时代的步伐，滚动升级.
所以微服务架构，既保护用户已有投资，又很容易向新技术演进。

微服务提供的能力，以及背后需要付出的代价。

• 单个微服务代码量小，易修改和维护。但是，系统复杂度的总量是不变的，每个服务代码少了，但服务的个数肯定就多了。就跟拼图游戏一样，切的越碎，越难拼出整幅图。一个系统被拆分成零碎的微服务，最后要集成为一个完整的系统，其复杂度肯定比大块的功能集成要高很多。

• 可独立部署和运行。但依赖一个高效的集群通信机制成为一个问题

• 单个微服务拥有自己的进程，进程本身就可以动态的启停，可无缝升级，但需要强大的版本管理和部署能力

• 可独立做负载均衡，提高性能和可靠性，动态伸缩，高可靠.

• 需要服务发现, 服务注册

• 服务的安全性, 监控, 降级, 权限控制, 熔断.

综上: 微服务，需要系统要提供一套基础的架构，提供微服务的底座功能, 支持微服务的松耦合和带来的优点.

需要以下：
1. 负载均衡
2. 服务注册, 发现, 依赖管理
3. 消息总线, RPC, MQ
4. 调用链
5. 日志(汇集)
6. 可用性保障, 服务降级，熔断等

什么样的服务能拆分为微服务：
1.职责业务独立
2.数据和逻辑独立, RPC调用的成本
3.与其他系统松耦合