背景，定义
原文：
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，微服务体系 激活了小团队，敏捷开发，团队以微服务的功能切分为界划分职责，划分团队
总结
好的设计，训练有素的团队才会带来胜利
技术较弱的团队，即使给了他们微服务的体系也很难保证不会乱
所以，通常建议是，以单体架构开始，随着系统负责，演进为微服务架构
