在我最初接触微服务的很长一段时间里，有两类问题都困扰着我和团队，这是让我印象最深的两类问题：程序员
- 没有配合微服务理念的团队
- 没有配合微服务理念的基础设施
后来，在和一些搞了微服务的同行屡次交流后，发现他们当初也面临和我相似的问题。数据库
此次就写写我最先搞微服务遇到的问题。服务器
有些问题放到如今来讲，已经有解决办法了，已经算不上问题了。可是不管怎样，这些问题若是能提早意识到，早作准备，会为未来搞微服务的同仁们省下许多的力气。网络
因此，这篇文章我会着重谈下这两类问题。架构
1、没有配合微服务理念的团队
当年，我仍是一个小开发团队的组长，组里将近 10 个程序员，维护着一个庞大的单体系统。框架
那时微服务刚出来不久，各类评估后，咱们认为把系统拆分红微服务能够带来更大的好处。运维
可是，对于微服务中提到的团队自治这点，因为当时的职位和经验限制，也没法贯彻这一理念，结果，最后就是把本身折腾了底儿掉。分布式
在谈团队自治的问题以前，我先说说拆分微服务的时候，咱们当时的总体交付流程是什么样的。微服务
总体流程很简单，业务提需求给咱们开发团队，而后开发团队收到业务需求后开发、测试，最后上线。工具
咱们上线流程也比较传统，先是开发人员把应用打包而后上传到一个运维团队规定的路径，而后才由运维团队发布到生产服务器上。
这种模式开始没什么大问题，但是随着咱们拆分服务越拆越多，问题出现了。
咱们负责的系统很重要，自己上线比较频繁。再搞了微服务以后，由于服务多了，服务器也多了，使得上线部署变得更繁琐。
这逐渐致使运维团队本就不富余的人手更加捉襟见肘，他们只能加班。结果就是，996 成了屡见不鲜，运维人员对此很有怨言。
频繁上线不但连累了运维兄弟，还拖累了其余团队——因为运维人手不足，又致使了咱们团队和其余团队项目上线常常出现冲突。
冲突发生后，由于咱们的项目是公司核心项目，很天然的，优先级咱们会占一些便宜。
其余团队的上线只能不断的调整去和咱们错开，或者加班等咱们上线后，再由运维安排他们的项目上线。
可见，在我搞微服务初期，微服务划分的快速迭代始终由于团队划分和微服务自己的理念不匹配，致使到处受挫。
若是你要全权负责一套微服务项目的时候，必定要万分注意。由于你自己的团队和微服务理念中的团队自治是不匹配的，这会致使你本身微服务项目的维护出现各类各样问题。
对于这类问题，我建议在初期你就要有所考虑。由于这个风险，或许是技术人员不可控的。
2、没有配合微服务理念的基础设施
在一开始，因为咱们的微服务是从单体项目逐渐剥离开来的，因此，在这个时候，服务只有 三、4 个。
可是随着对业务理解愈来愈深刻，开发人员也对服务落地愈来愈熟悉，服务划分的速度也愈来愈快了。在很短的时间内，服务一会儿从三四个，猛增为了近二十个。
这时候，面对猛然暴增的服务，我一会儿不知所措了。
除了上面说到的运维上线的问题，还出现了不少我从未经历过的问题。
1. 定位问题成了一件很奢侈的事
经过采用上线模板和其余工具，好不容易缓解了运维问题。还没轻松几天，紧接着，故障处理又出现问题了。
开始的时候，服务数量少，定位问题，大概稍微琢磨下，就能判断出来。可是，随着服务越分越多，定位问题就很麻烦了。
例如出问题后查日志，原来的服务数量少，查日志直接上服务器就查了。可是，如今服务有接近二十个，还没算集群。挨个服务器查日志定位问题，那几乎不可能。
2. 不能再这样了，否则失败就在眼前
后来，我下了决心，在解决这些问题以前，坚定不能再拆新的服务了。
我主动去和领导沟通了这些问题，获得了领导的支持。而后，又拉着领导和业务团队磨了好几回，终于也让他们赞成暂时下降一段时间提需求的频率。
总算能腾出精力解决问题了。
3. 关于问题的思考
这些问题，我通通归类为基础设施的问题。其实，那时候虽然微服务生态尚未彻底清晰，可是，我自己大概也总结出了一些套路。
我把须要的基础设施分红了两个类别:
- 部署发布
- 平常运维
而后，我分别对这两类基础设施的需求又作了进一步的细化。下面把当时我作的最紧急的一些基础设施需求列了出来:
4. 我控制不了这些问题……
可是，这里依然还有问题。
好比，这些工具理论上是属于基础设施，是否是须要运维团队来维护？但是运维团队已经对咱们的各类上线需求不胜其烦了。
又好比，这些工具当时不成熟，咱们还得本身开发改进，而这又要靠谁呢？
当时没有办法，我只能咬牙本身带了几我的，把这些额外的工做承担了下来，由咱们几我的专门开发和维护这些工具。
一直到后来，市面上有了成熟的工具链，我自己也升职，能够对技术团队总体去贯彻 DevOps 理念了，才真的从这些任务中解脱开来。
5. 基础设施决定上层建筑啊，同志们
我知道不少公司是技术本身提出来微服务的，提出来的时候，你必定要清楚，微服务这套体系自己，
把之前单体系统的复杂度转移到了技术基础设施上。
不少工做实际上是须要自动化的。在踏进微服务这个神坑前，必定要考虑清楚：公司有没有合适的基础设施？
3、落地须要妥协的其余的一些细节问题
微服务理论看上去是很完美的，可是，在现实落地，其实还会有许许多多不太可能立刻完美贴合微服务理论的问题。
我大概列举几个重要的:
1. 数据库划分的问题
老实讲，我们这篇文章原本就是在说一个服务一个数据库的模式。那么按理来说，严格符合这个模式是最好的。可是，实际落地来说，中间有太多的弯弯绕绕了。
好比，咱们的服务须要划分红四五十个服务，这个时候，数据库划分红一样的四五十个库就不合适了。由于这会引入以下的三个问题:
-
数据库管理过于复杂——这个是很显然的问题，管理几个数据库和管理几十个数据库，须要投入的人力物力是彻底不同的。每一台数据库自己就是个很复杂的系统，数量越多，出问题的概率也越大，监控难度也越大。
-
分布式一致性实现太过复杂——数据库数量上来了，由于业务须要，协调数据一致性从原先须要协调几个数据库的状态变成了须要同时协调几十个。复杂度一会儿上去了，这也会形成不少没必要要的技术问题。
-
跨库查询至关不方便——这个问题也是同样的，当咱们服务划分后，数据库若是也划分的过细，那么之前须要跨几个库查询的业务，就可能变成须要跨十几个库查询。
因此，就落地的时候来说，仍是须要有个业务域的概念。这也是为何微服务总和领域驱动设计绑定在一块儿，由于人家自然有个业务域的概念。
这时候，就能够考虑某些业务域，共享一些数据库。好比，订单业务域能够每一个服务对应一台数据库，可是，用户业务域可能就能够共享那么一台数据库。
2. 开发框架的问题
我搞微服务比较早，因此，开始作的时候，就是用了 Spring 的框架，而后每一个 Tomcat 后面放个服务。
那时候，维护起来真麻烦。由于 Tomcat 自己多了，又和应用不是一体的，同时维护 Tomcat 和应用，很是难受。
后来有了 SpringBoot，状况好了不少。再后来，咱们也尝试使用了一阵子 Dubbo。
其实各有本身的不足。
SpringBoot 的不足主要是，用了 SpringBoot，不少时候就不得不用更多的 Spring 其余组件，哪怕它的一些组件很不让人满意。感受项目中到处 Spring，非得走 Spring 那套规则不可。
Dubbo 的不足主要是能配合的组件不多，咱们用 Dubbo 其实很早，可是为了和 Dubbo 配合，有些时候还得作不少额外的开发。好比，当时 Dubbo 自己服务跟踪，也没有经过 RabbitMQ 通讯的组件，咱们都须要本身开发。
因此，当你要选框架的时候，要考虑清楚，由于微服务自己是一大套生态。若是框架自己选用不合适，后期就得靠本身的技术能力去作硬调整。
3. 一些关键技术什么时候引入的问题
有些关键技术，咱们是逐渐引入的。
由于，引入一个新技术，对咱们不管是开发仍是维护，引入便利性的同时可能也会引入复杂性。
好比容器技术，咱们就是搞了好久了才慢慢引入的。引入容器技术后，不少问题（例如网络、内存）咱们就要多想一层，看看是否是由于容器致使了其余问题。
总之，对于一个正在运营的系统，我我的认为引入新技术须要谨慎评估。
最后
以上写的主要是我和团队的经历，可能你会以为是一家之言。不要紧，说的不对的，欢迎指正，虚心接受；说的对的，但愿能让给你们一些借鉴
对于一个服务一个数据库说到如今，我说了为何要分服务，以及如何落地还有带来的一些问题。
对于这种模式，它引入的问题其实很是多，一本书可能都说不完，这里只是举了一些我遇到的一些我记忆里很深入的问题。
那么，把一套系统改形成一套微服务就须要分服务和分库就完了吗？解决分服务和分库带来的一些问题就完了吗？
那可不是，由于有些问题非得引入一些新的模式才能最好最省心的解决，只有把多种微服务的模式配合起来，才能让微服务这个生态彻底的运转起来去替代之前的单体项目生态。
在后面的文章里，我会讲解该怎么用模式去解决一些棘手的性能问题，怎么用模式去平衡读写负载失衡的问题等等。只有经过模式把分服务引发的各类开发问题解决了，一套微服务系统咱们才能说架构彻底成功了，因此，我会以个人架构经验去把整套微服务架构经过模式去讲清楚一套微服务到底应该如何架构。
你好，我是四猿外，一家上市公司的技术总监，管理的技术团队一百余人。
我从一名非计算机专业的毕业生，转行到程序员，一路打拼，一路成长。
我会把本身的成长故事写成文章，把枯燥的技术文章写成故事。
欢迎关注个人公众号：四猿外