内容简介：什么是微服务？网上有很多文章，看完之后似懂非懂，理论上扯太多，不如实践体会的真实。以我工作中实践的所谓“微服务”，就是把业务进行拆分，模块化，独立成一个个的服务。这样来看并不能体现出“微”来，因为即使进行了拆分，有些服务还是会随着业务的增长逐渐变“大”。我姑且叫它“多服务”吧。原本微服务的想法是模块化开发，互不干扰。但是由于我们有针对每个端都有一个壳子服务（在我们的架构中是直接对接前端的那个服务，也有人称这个为gateway）。导致每次开发至少会涉及到两个服务，一个是模块化的基础服务，一个是“壳子”服务，甚
微服务的概念
什么是微服务？网上有很多文章，看完之后似懂非懂，理论上扯太多，不如实践体会的真实。以我工作中实践的所谓“微服务”，就是把业务进行拆分，模块化，独立成一个个的服务。这样来看并不能体现出“微”来，因为即使进行了拆分，有些服务还是会随着业务的增长逐渐变“大”。我姑且叫它“多服务”吧。
多服务的痛点
开发和发布
原本微服务的想法是模块化开发，互不干扰。但是由于我们有针对每个端都有一个壳子服务（在我们的架构中是直接对接前端的那个服务，也有人称这个为gateway）。导致每次开发至少会涉及到两个服务，一个是模块化的基础服务，一个是“壳子”服务，甚至是三个。这样就会导致一次业务的开发，可能需要编写两三个服务的代码。发布也需要发布两三个服务。回滚也一样。如果你开发的服务中同时存在同事上线的代码，回滚起来就是一件很蛋疼的事情（当然，这种事情应该做到0发生，但也无法绝对避免）。
线上问题排查
由于一个接口的调用链可能达到3层或4层，导致问题的排查低效，定位和修复的速度不够快，影响用户体验。
流量问题
有一种情况是，很多服务都依赖于同一个服务，导致该服务的流量非常的大，常常会看到线上有502、socket hang up等，各种之前从没有碰到过的网络问题。虽然暂时无法排查到根本的原因，但一个明显的事实是流量上来之后才出现这些奇怪的问题。
服务的管理和维护
我们的微服务是部署在 docker 集群的，由于对docker的使用和理解不够深入，导致出现问题的时候无法快速解决，从而影响了业务。
总结
技术不够，实践微服务一定是会遇到麻烦的问题的。
微服务可能最重要的一点是业务的划分吧。
微服务需要完善的东西很多，比维护一般的服务要求高很多。
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网
猜你喜欢:
- 微服务开发痛点实践分享——Apache ServiceComb | 视频
- 安盟信息解决智慧医院建设“痛点”
- 安防的“致命”痛点：场景碎片化
- blink 解决的一个 flink 分析痛点
- 机遇与痛点齐飞的目的地营销
- 后期数据库主从架构的痛点，真的痛
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
