性能依赖于它人：
- 实现一个功能时候难免会跟其他微服务进行交互，一交互就可能出现网络延迟，内网虽然很快，但是也是有延迟的。
- 自己代码遇到性能瓶颈，自己会想办法去优化他，但是调用其他微服务性能慢怎么办？要么催人家去优化，要么就忍着咯
- 对方服务挂了呢，那自己服务也就GG了?
- 改进：
- 该RPC吧，听说效率会快一些，
- 试着添加下缓存看看
- 如果挂了，丰富日志可以快速定位
数据独立：
- 一般一个模块一个微服务，一个微服务一个数据库，这就造成很多数据静静躺在数据库里发挥不出他的价值，当然你可以找人家要，但问题是有没有这个接口是个问题，要是在涉及跨部门，那就难上难咯
- 改进：
- 应该有专门部门或者小组专门备份这些数据，并将他们导入数据仓库，然后做好分级，提供给专门人员使用
接口不能随意动：
- 一旦接口放出去给别人调用，里面返回值就不能改了，因为你永远不知道谁在用，用了啥？换个大小写引发服务罢工的惨啊也不是没有遇见过
服务多了，运维难了
- 运行一段时间服务迁移到别的机器上，这内网地址一变，关联服务都要变
感受：
还是那句老话，具体问题具体分析，虽然工作中习惯将一个系统拆成多个微服务然后进行分工，但是有时候也会将一些自身自成一系的，扩展少的系统采用单体程序实现。记住一个新理念或者新技术出来往往是为了解决当下一些新的问题，而不是去代替什么，所以微服务也好，单体程序也罢，都要评估后在下决定。
