认识达内从这里开始

认真做教育专心促就业

贵阳达内培训微服务架构都有哪些不足之处

发布：贵阳达内培训
来源：互联网
时间：2022-01-27 13:42

微服务架构应用我们在前几期的文章中已经给大家介绍过很多次了，而本文我们就再来了解一下，微服务架构都有哪些不足之处。

贵阳达内培训微服务架构都有哪些不足之处

需要维护更多的基础设施

每多一个新服务，就会增加一些基础设施。比如，一个ECS服务、一个Postgres实例或一个RabbitMQ实例。CI/CD的配置也会增加，还需要进行三方服务(比如Rollbar/Sentry)配置。依赖也需要更新，而且需要更新依赖的地方越来越多。基础设施团队在项目上花了很多时间，为每一个服务重复着枯燥无味的工作。

无人照看的服务

小型的服务容易被人忽略，在运行起来之后，基本上会被搁在一边，后就会过时。

一个微服务如果半年没有被动过，人们一般就不太会去修改它，其中有90%的修改都是依赖更新或基础设施更新。也就是说，我们给自己增加了额外的维护负担。

更慢的功能开发

如果服务边界没有搞清楚，会显著降低功能的开发速度，这是微服务的一个很大的风险点。开发一个跨多个服务的功能需要做更多的工作，而重构一个跨多个服务的功能是一个噩梦。如果服务边界很清晰，大部分项目只会影响到一个服务。但是，对于初创公司来说，它们的发展方向是不可预测的。一个产品的两个部分在一开始可能是完全独立的，但一年之后可能会变得紧密耦合起来。所以，要完全清晰地定义服务边界不是件容易的事。

依赖库

为了让所有微服务使用同级的依赖，我们需要从单体拉取依赖库，而更新这些依赖库成了我们的一个痛点。更新依赖库需要发布新版本，如果库很重要，需要在很多地方做出更新。

技术大杂烩

微服务带来的一个好处是“技术多样性”，但它后会变成一个问题。我们的单体是用Django开发的，而我们的部分微服务使用了Flask。单体使用Celery处理异步任务，而部分微服务使用了RabbitMQ。有一个微服务使用了DynamoDB，而其他微服务使用了Postgres。

后来，我们花了很多时间重构微服务，让所有的微服务都用上同样的技术。因为一些库依赖了某些特定的技术，而我们的一些微服务无法使用它们。另外，技术多样性会给新加入的开发人员增加难度。

本地开发问题

随着微服务数量的增多，在开发时就需要在本地运行更多的服务。应用程序的容器化确实帮了我们一些忙，但相比之前，我们不可避免地遇到了更多本地开发问题。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。

< 上一篇：贵阳达内培训白盒测试与黑盒测试都有哪些区别

下一篇：贵阳达内电脑培训go语言编程应用注意事项 >