微服务访谈
我们是2017年、2016年的时候开始做微服务，然后2017年的时候，基本上就把那个当时创业的时候做的一套微服务就上线了
但是，真正因为那个时候，其实还有欠一些欠缺吧，包括当时的微服组件都不是很齐全，
所以我觉得效果并不是特别的好
不过它最大的优势就是它上线完了以后呢，能够很长时间的不需要什么人去运维，它就是它的这个是恢复能力很强
然后呢，我们现在这公司呢，它的微服务栏其实是做的更我觉得更轻一些
这个主要在设计的时候，就要区分出业务相关性的一些东西给他抽取出来。这样子的话，其实微服务它不不纯粹是一个基础架构或者是这种应用架构的问题，他跟实际的业务有关系，用解耦的方式有很多，比如说什么消息队列啊，后台的定时任务啊，这些都需要把它好生的，我认为是要拆拆分出来
早期做微服务，所以说坑比较多，因为组件不全，还有这个认知上面也有一些这个叫做不成熟吧。你必须要相当于是先去实践一次以后，你才知道这个微服务它哪些有坑。然后，其实有些地方是不能用微服务的
所以我们在这个19年的时候到这家公司做的时候，其实我最先提的不是微付，先做的是组件化啊。组件化先做完然后再做容器化啊。容器化做完然后再做那个叫做消息队列啊，解耦，然后最后才上的就是微服
这个东西啊，就是说要设定一些规则啊，就是所谓的最佳实践之类的啊，没有一个就是说是最好的解决方法，只有一个比较适合解决方法啊
你看啊，这个就不同的这种叫做实践，它有不同的这种解决方案，你也不能说它没有道理。但是呢，从这个整体应用的框架的角度来讲，你这儿写一点儿sql，那儿写一点儿sql，到处都是sql，对吧？那么你这个就没有达到复用的角度。所以说*，这这一块的话，我们就给他否了
所以说，你说有时候其实这些设计这些东西啊，都是比较两难的。他说这个东西，我可能一个小时就搞定了，对吧？你要去做什么设计？你可能怎么也得折腾三四天去了。你你这个你看，这个就是，开发人员跟到设计人员的思路是不一致的
你说是基于架构的设计，还是基于功能的设计？这个它有时候是有对立面的。你对于架构的设计的话，你是希望它能够复用。对于功能的设计来讲，多数情况下就是能用啊，所以这个时候是有矛盾的
还有就是云产品的时候，云产品是隐藏成本多。我们基础架构除了，数据库之外，基本都自建。redis， mongodb, rabbitmq.
另外多环境，一套的环境主机是企业内容，一套生产全云。 如果全建在云上话，费用也很高。