本文主要是介绍当年一穷二白搞微服务的日子……我太难了，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
在我最初接触微服务的很长一段时间里，有两类问题都困扰着我和团队，这是让我印象最深的两类问题：
- 没有配合微服务理念的团队
- 没有配合微服务理念的基础设施
后来，在和一些搞了微服务的同行多次交流后，发现他们当初也面临和我类似的问题。
这次就写写我最早搞微服务遇到的问题。
有些问题放到现在来说，已经有解决办法了，已经算不上问题了。但是无论怎样，这些问题如果能提前意识到，早做准备，会为将来搞微服务的同仁们省下许多的力气。
所以，这篇文章我会着重谈下这两类问题。
一、没有配合微服务理念的团队
当年，我还是一个小开发团队的组长，组里将近 10 个程序员，维护着一个庞大的单体系统。
那时微服务刚出来不久，各种评估后，我们认为把系统拆分成微服务可以带来更大的好处。
但是，对于微服务中提到的团队自治这点，由于当时的职位和经验限制，也无法贯彻这一理念，结果，最后就是把自己折腾了底儿掉。
在谈团队自治的问题之前，我先说说拆分微服务的时候，我们当时的整体交付流程是什么样的。
整体流程很简单，业务提需求给我们开发团队，然后开发团队收到业务需求后开发、测试，最后上线。
我们上线流程也比较传统，先是开发人员把应用打包然后上传到一个运维团队规定的路径，然后才由运维团队发布到生产服务器上。
这种模式开始没什么大问题，可是随着我们拆分服务越拆越多，问题出现了。
我们负责的系统很重要，本身上线比较频繁。再搞了微服务之后，因为服务多了，服务器也多了，使得上线部署变得更繁琐。
这逐渐导致运维团队本就不富余的人手更加捉襟见肘，他们只能加班。结果就是，996 成了家常便饭，运维人员对此颇有怨言。
频繁上线不但连累了运维兄弟，还拖累了其他团队——由于运维人手不足，又导致了我们团队和其他团队项目上线经常出现冲突。
这篇关于当年一穷二白搞微服务的日子……我太难了的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
