Microservice上车不废话之一 ：定义 原则 好处

背景，定义

原文：
https://howtodoinjava.com/microservices/microservices-definition-principles-benefits/

单体服务太难维护

更新慢，如履薄冰

mono.png

微服务 切割清楚职责，修改一个内部对其他微服务没有影响

微服务间 Http Rest 通信，或者消息队列等

原则：

• 单一职责

• 我就负责用户鉴权，其他功能都给我滚远点，老子不管

• 聚焦于业务逻辑

• 微服务内部肆意使用新技术，只要能满足业务需求

• 不用像之前单体结构项目下，种种约束

• 尽情使用最适合的技术

• 你构建他，你拥有她

• 一个团队构建这个微服务，到上线和后期维护都在你的掌控下

• 运维？失业了(😝)

• 基础服务自动化

• 微服务所依赖的东西，全部打包成一个fat jar ，

• 有机会你把她扔进docker帅不帅？

• 用一个独立的java process来运行才最酷

• 为容错而设计

• 系统要有弹性，一个服务挂了咋办，得能快速检测到谁挂了，

然后要自动恢复啊

微服务体系中各个服务的健康是需要实时监控第

微服务好处

1， 每个服务可以选择合适的技术，更高效

2，简单，短小精悍，快速试错

3，弹性，扩容代价小

4，自由切换，不同微服务间替换便捷

5，微服务系统 增加功能，对已有系统影响小

6，每个服务内部技术栈的变化，对其他微服务影响极小

7，同一环境下，同一个服务可以有不同版本同时在跑

8，微服务体系 激活了小团队，敏捷开发，团队以微服务的功能切分为界划分职责，划分团队

总结

好的设计，训练有素的团队才会带来胜利

技术较弱的团队，即使给了他们微服务的体系也很难保证不会乱

所以，通常建议是，以单体架构开始，随着系统负责，演进为微服务架构