マイクロサービスがソフトウェア エンジニアリングの特効薬ではない 10 の理由

こんにちは、私はエントロピー削減です、言葉を顔として見てください。

マイクロサービスは、アプリケーションを小さな独立したサービスに分割することで、アプリケーションの拡張性、保守性、テスト容易性を強化するように設計されたソフトウェア アーキテクチャ スタイルです。

マイクロサービスはソフトウェア開発に多くの利点をもたらしますが、すべての状況において常に最適な選択であるとは限りません。

言い換えれば、マイクロサービス アーキテクチャはソフトウェア エンジニアリングにとって特効薬ではありません。

したがって、技術チームがマイクロサービス アーキテクチャを使用するかどうかを検討する際には、次の 10 点を慎重に検討する必要があります。

複雑さが増す

この世に無料のものは何もありません。マイクロサービス アーキテクチャを実現するには、サービス検出、負荷分散、サービス間通信など、大量のサポート インフラストラクチャが必要です。これらのメカニズムやシステムにより、システムの複雑さが増し、保守コストが高くなります。

マイクロサービスは、アプリケーションのスケーラビリティや保守性などの多くの問題を解決できますが、単一の解決策ではありません。DevOps、CI/CD、コンテナ化などの他のテクノロジーやベスト プラクティスと組み合わせて使用​​する必要があります。

より難しいテスト

マイクロサービスアーキテクチャを利用すると、システムのテスト作業がより複雑になります。最終的にシステムの品質を保証するには、各サービスに必要な個別のテストに加えて、依存する他のサービスと一緒にテストする必要もあります。

導入にコストがかかる

マイクロサービスには、より多くの開発、展開、テストの労力が必要であり、より多くのサーバー リソースが必要です。

中小規模のアプリケーションや単純なシステムの場合、マイクロサービス アーキテクチャは複雑すぎて高価すぎて、採用する価値がない可能性があります。

O&Mコストが高くなる

つまり、各サービスは非常にシンプルであり、100 のサービスを管理するよりも 1 つのサービスを管理およびサポートする方が常に簡単です。

マイクロサービス アーキテクチャを使用する場合、複数のサービスを管理および監視する必要があるため、多くの運用および保守リソースのオーバーヘッドが増加する可能性があります。

マイクロサービス アーキテクチャの下では、開発者は依然としてサービスの設計と実装、監視やトラブルシューティングなど、多くの作業を行う必要があります。

デバッグはさらに困難になる

マイクロサービス アーキテクチャの最大の課題の 1 つは、分散システムではシステムの問題を特定してデバッグすることが非常に難しいことです。

大規模な分散マイクロサービス システムでは、問題の根本原因を見つけて特定することが難しいことは自明のことです。たとえば、複数のシステムで情報を取得する必要がある場合、複雑な呼び出し関係と相まって、情報を統合および連結する前に明確にする必要があります。

システムの遅延が長くなります

マイクロサービスはネットワーク経由で相互に通信するため、システムに追加の遅延が発生する可能性があります。

所以,对于时延要求较高的场景,就需要慎重考虑微服务的调用层级关系和具体的代码实现方式,以满足场景所需。

难以理解的系统

当系统内多个服务独立开发和运行时,我们就很难以掌握系统整体的运行状况了。

系统之间是如何组合的,调用请求是如何流转的,数据是如何传递的等。

都会让理解成本增加不少,系统变得难以掌控,可观测性降低,分险也就增加了。

需要专职团队

微服务并不是无代价的。

微服务架构的有效落地,需要一个具备分布式系统、网络和DevOps专业技能的团队。

采用微服务架构需要大量的投资,例如培训、开发、测试、部署和维护。

企业需要考虑这些成本,并权衡微服务架构的优点和缺点。

安全的问题

微服务并不是无风险的,保护微服务架构比保护单体应用更具挑战性。

采用微服务架构可能会引入新的风险,例如服务之间的通信问题、服务部署和版本控制问题、以及依赖关系的复杂性。这些风险需要被认真评估,并且需要采取适当的措施来减轻这些风险。

并不总是必要的

微服务并不是适用于所有团队的。

采用微服务架构需要更高的技术能力和开发经验。

对于一些中小型团队或初创公司来说,可能没有足够的资源和技能来开发和维护微服务架构。

因此,需要根据团队的技能和经验,以及项目的规模和复杂度来评估,是否适合采用微服务架构。

微服务不是一个必选项,只是一个可选项而已。

最后

尽管微服务架构在很多情况下可以提供一些优势,但也需要根据具体情况进行评估和决策。

技术团队,需要考虑技术和业务需求,以及组织的能力和资源等多个方面,并综合权衡微服务架构的优缺点,才能做出正确的决策。


阅读,思考,练习,分享,日日不断之功。

嗯,写完了。

新的一天,加油哦 (ง •̀_•́)ง

おすすめ

転載: blog.csdn.net/peida/article/details/130613341