SOAサービスへのマイクロからは、分散型エンタープライズアプリケーションアーキテクチャは、どのようにネイティブクラウド時代を再構築するには？
HTTPS：// yq.aliyun.com/articles/720090?utm_content=g_1000078933 コンテンツとあなたが学ぶために数回読む必要があることは非常に注意を払っています。
アリの姉妹REVIEW：十年以上前に、分散システム開発の様々なから現在のコンテナクラウドに、各新規事業開発に既存のインキュベーターを支えるからは時代の不可分の統一技術アーキテクチャです。この記事では、クラウド・コンピューティング・アーキテクチャの変化は、より多くの企業のIT変革、その機敏な力になるために市場での競争を促進するためのクラウドコンピューティング技術の使用を助けることを望んで、分散型エンタープライズアプリケーションアーキテクチャレベルからネイティブの提供について説明します。
21世紀では、我々は、クラウドネイティブアプリケーションアーキテクチャの進化に、マイクロサービスアーキテクチャに、SOA（サービス指向アーキテクチャ）からエンタープライズ分散アプリケーション・アーキテクチャを目撃しました。
エンタープライズアーキテクチャ記述の進化の考え方ためには、いくつかのは、形而上学について話しましょう。
- まず、熱力学第二法則に沿って、企業のITシステム（エントロピー）の複雑。時間の控除では、ビジネスの変化は、企業のITシステムの複雑さが増加しています。
- 第二に、コンピュータの相互作用の設計では複雑[1]の保全のよく知られた法律があります。対話型アプリケーションの複雑さは唯一の別の方法が存在し、それを置くために、消えません。この原理は、ソフトウェアアーキテクチャに適用されます。新しいソフトウェアアーキテクチャの導入は、ITシステムの全体的な複雑さを軽減しません。
あなたがしたいかどうかの人生は、このことを聞いているだけではなく、私たちは少し冷静さを感じて投げますか？
現代のソフトウェアアーキテクチャのコアタスクの1つは、直面する必要があるアプリケーション開発の複雑さを軽減、国境インフラストラクチャとアプリケーション、合理的なセグメンテーションの複雑さが定義されています。換言すれば、開発者は、技術革新のコアバリューに集中できるよう、そして解決するために右の人とシステムにいくつかのより多くの質問を置くことです。
私たちは、分散型アプリケーションアーキテクチャの進化の背後にビジネスロジックを探る、下の画像から開始しました。
変態の痛み：SOA
R＆DとTL建築家が世界中の顧客の範囲に関与して2004年に、IBMは、I、Pepboys、オフィスデポや他の国際企業がビジネスの俊敏性を高め、企業内や企業間のビジネスプロセスを最適化するためにSOAを使用する際に役立つパイロットプロジェクトをグローバルSOAデザインセンターを設立しましたセックス。
大きな画像は次のようになります。経済のグローバル化が徐々に深化によって、企業は競争の激化に直面し、ビジネスの変化が加速し始めました。進化の数十年を経た大規模なエンタープライズITシステム内では、システム全体は、ホストシステムは、そのようなCISC / COBOLの取引アプリケーション、業務システムにおけるミニコンピュータAS400 RPG、およびX86 /上で共存する、非常に複雑な技術になると電源および他の分散システムC / JEE / .NETアプリケーション。
サードパーティベンダーが提供する多数のアプリケーションは、いくつかのシステムでも何のメンテナンスを持っていません。そして、繰り返しのビジネスに、いくつかの新しいビジネスシステムは、システム間の有機リンクの欠如、島の数の形成を導くために起因する合理的な方法論の欠如のため、継続的なビルドアップしているITインフラストラクチャの複雑さを増加し続け、ビジネスをサポートすることはできません開発願望。これは、短時間の傷害を緩和することができますが、被害者がLinghu、異種腹立たしいは、体内に入るのを助けるために習得するように見えました。しかし、ダウン傷つけるプラス傷害ます長い間お互いを撹拌し、マルチチャネルの統合を腹立たしいありません。
そのため、IT企業が直面する主な課題は、大きな垂直バレル内企業の数（サイロ-ED）ITシステム、ますます複雑なビジネスプロセスをサポートし、効果的なビジネス上の意思決定およびサポートサービスの急速な変化の統合です。
この文脈では、IBMおよび他の企業は、企業を向上させる、ビジネスプロセスを通じてサービスを柔軟に組み合わせることができ疎結合サービスアーキテクチャを構築し、より粗粒度のサービスにSOA（サービス指向アーキテクチャ）の概念、抽象アプリケーションシステムを提案していますIT資産の再利用、「情報の島」問題に対処するために適応性、柔軟性と拡張性を向上させます。
SOAは、分散システムを構築するための一連の原則を提示し、これらの反射は、今日でも適用されます。
- 明確に定義された標準化されたインタフェースを持つサービス。私たちは、開発へのコードの最初のアプローチではなく、使用されるべきサービスの説明や契約、最初のサービスによって定義されたデカップリングするサービスコンシューマ（サービスコンシューマ）とサービスプロバイダ（サービスプロバイダ）を達成します。システムの可用性と拡張性を改善するために、同期または非同期通信を選択する柔軟性を達成するために、他方では、分離型言語を解決することができるドキュメント指向RPCプロトコルメッセージの代わりに、特定の言語、およびサービスを使用してサービス間の通信。
- サービスが疎結合されなければならない、そこに、何時間、空間、技術もないサービス間のチームに頼る必要があります。
- サービスは、サービスコールとデカップリングセッションコンテキスト状態を作り、ステートレスである必要があります。
- サービスは、サービスの実装は、独立して展開することができ、バージョン管理、自己管理と回復自律的かつ自己完結型である必要があります。
- サービスを組み合わせることができることが見出されています。例えば、サービスは、サービス・レジストリを通じてサービスコンシューマとサービスプロバイダの動的バインディングを達成するために見つけることができます。ビジネス・プロセスのオーケストレーションは、異なるシステムからビジネスサービスに組み立てることができます。
ときに最初のビルドSOAシステム、彼らは、通信リンクを指すようにポイントを使用して、サービス呼び出しロジックは、アプリケーション統合の実装に埋め込まれています。このように、サービスの数は、実際に開発を簡単かつ効率的な方法であるとき、比較的小さいです。しかし、最大の問題は、サービス間の大きさで成長して、通信サービスがより複雑になる、との接続経路の複雑さは、サービス巨大なガバナンスの課題に急増する、ということです。
これらの課題に対処するために、エンタープライズ・サービス・バス（エンタープライズサービスバス、ESB）が導入されるようになりました。エンタープライズ・サービス・バスは、サービス（接続）との間の接続を提供して変換（transformantion）、および仲介（仲介）に対処する能力があります。そして、企業内の様々なサービスは、ITインフラストラクチャの柔軟性を向上させ、内部情報の共有のコストを削減し、システム統合の複雑さを遮蔽する、情報システム間の疎結合を達成するために、サービス・バス・アーキテクチャに接続することができます。
SOAの方法論は、私が使用されるように易筋経は、異なる腹立たしい、支配を集める行く、ソート助けることができるというようなものです。しかし、栽培過程は容易ではありませんでした。野心的なSOAの多数のプロジェクトが望ましい結果を達成できませんでした、これは背後にある理由は何ですか？
どれでも成功したITアーキテクチャでは、ビジネス目標、技術インフラストラクチャと組織能力と併せて、互いに不可分です。
ビジネスでは、時間がSOAエンタープライズITの株式市場の問題を解決するに焦点を当てています。これは、かなりの程度までSOAの方法論は、エンタープライズアプリケーション統合（EAIエンタープライズアプリケーション統合）と狭くされます。
SOAの哲学において、情報システムとの間の経絡を開き、企業を維持するように、柔軟、それはアジャイルインフラストラクチャ、最初のステップであるが、企業のITインフラストラクチャの反復再構成のために内部強度を秀事業における開発および変更をサポートし続けます。
組織構造は、その時点で、企業のIT部門の多くは、コストセンター残るビジネスサポート部門の子会社であるため、ほとんどの企業は長期的に欠けているITは戦略計画、ITチームは、成長の欠如、SOAシステムの操作と減少したプロジェクトを認識しました何のセキュリティと継続的な投資を組織していません。
場合でも、プロジェクトの成功は、時間をかけて複雑に積極的で、徐々にその活力を失うことになります。当社の顧客はまた、その既存店全国のビジネスをサポートする業務システムを構築するためにアメリカの生活の友人で昨年は15年前、私に写真を送りました。これは、企業の技術戦略の欠如を反映し、成功した技術プロジェクトです。
技術的には、ESBアーキテクチャは、ビジネスロジックを実装し、サービス統合デカップリングは、より良い集中管理サービスを管理することができますが、だけでなく、いくつかの深刻な問題を暴露しました：
- 過度の業務システムの再利用性を重視ではなく、ガバナンス、企業のITインフラの再建に。サービス統合ロジックの多数内部ESB（右端上記のように）に沈むように実装され、ロジックは、維持するのは非常に困難であり、移植が困難は、拡張ESB負担になります。我々は適切に正しい場所に複雑さを処理しなければならないし、単純に譲渡することはできません。
- ESBは、集中メッセージングシステムに基づいておりますが、インターネットの急速な発展で、ESBは、成長規模なエンタープライズITの課題に対処することができませんでした。
- ESBスマートパイプシステムアーキテクチャのように、ダムエンドポイントは、急速に変化するインフラや公共革新に適応することができません。
類推ビットは、通信事業者は、会議だけでダミー電話端末は、豊富な通信サービスを楽しむことができ、通信インフラに呼び出して、複雑な機能のビデオ通信を期待していました。しかし、スマートフォンの普及で、マイクロチャネルとネイル分散型コラボレーションツールなどの技術革新は、人々のコミュニケーション方法に革命をもたらしている、と電気通信ネットワークは、パイプラインの運命を返します。
米国の出現：マイクロサービス
インターネット、モバイルインターネット時代の到来特にの発展に伴い、世界の経済構造は大きな変化が変更施しました。ITは、伝統的な録音のシステム婚約のシステム（例えば、フルチャネルマーケティングなどのインタラクティブシステム）の進化（例えばERP、SCM、などなど取引システム）から焦点を当てエンタープライズ。
これらのシステムは、インターネット規模の急速な成長にも対応できるようにする必要があり、かつ急速に反復処理し、試行錯誤のコストすることができます。ITは技術革新の駆動エンジンの一つとなっているエンタープライズ、理想的な技術は、さらに、エンタープライズITの進化を加速するために、ビジネスの境界はまた、ITチームミッションのより良い感覚を助ける展開します。
マイクロサービスアーキテクチャ - Netflixの、アリで、インターネット企業のシリーズは新しい変化の企業構造を支配しました。Apacheのダボは、そのようなマイクロフレームワークとしてのSpringクラウドサービスが広く用いられています。
核となるアイデアは、アプリケーションの機能を分割し、ミクロのサービスをデカップリング、業務システムの実装の複雑さを軽減することです。マイクロサービスが疎結合解体サービスのセットとしてアプリケーション機能は、各単一責任（シングル責任の原則）の原則に準拠していることを強調しました。マイクロサービスアーキテクチャは、従来のモノリシック・アーキテクチャに固有のいくつかの問題を解決します。各サービスは独立して配信展開することができ、大幅にビジネスの俊敏性を高めるため、独立して、横方向膨張/収縮の各サービス、インターネット規模の挑戦。
マイクロサービスアーキテクチャの元の定義からマーチンファウラー[3]
もちろん、複数のマイクロサービスへの大規模なモノリシックなアプリケーションの解体は、確かにITシステム開発の調整、配信、運用、保守の複雑さを増加します。このときマイクロサービスアーキテクチャと自然の血管DevOpsチームと一緒に来て、ネイティブクラウドアプリケーションアーキテクチャのプロトタイプを構成します。
マイクロサービスアーキテクチャは、SOAのアーキテクチャの原則を継承するが、実装レベルでは、ダムパイプの分散アーキテクチャスタイルの中心にインテリジェントエンドポイントとESBを構築することによって交換される傾向にあります。
マイクロサービスアーキテクチャは、第1の分散アーキテクチャの内因性の複雑さに直面しなければならない、分散コンピューティングの誤解を参照してください[4]。マイクロサービスフレームワークは、このようなサービスの発見、溶断、電流制限、リンクを追跡課題などの複雑な通信やサービスの管理サービスを、解決することができるようにする必要があります。
このようHSF /ダボ方式やSpringクラウドコードライブラリとしてマイクロサービスフレームワークは、これらの機能をカプセル化します。コードベースは一緒にアプリケーションとメンテナンスのリリースでは、アプリケーション自体に内蔵されています。
服务通信和治理本质是横向的系统级关注，是与业务逻辑正交的。但在微服务架构中，其实现方式和生命周期与业务逻辑耦合在一起的。
微服务框架的升级会导致整个服务应用的重新构建和部署。此外由于代码库通常与特定语言所绑定，难以支持企业应用的多语言（polyglot）实现。
进化之光：云原生
SOA 采用中心化的服务总线架构，解耦了业务逻辑和服务治理逻辑；微服务架构回归了去中心化的点对点调用方式，在提升敏捷性和可伸缩性的同时，也牺牲了业务逻辑和服务治理逻辑解耦所带来的灵活性。
为了解决上述挑战，社区提出了 Service Mesh（服务网格）架构。它重新将服务治理能力下沉到基础设施，在服务的消费者和提供者两侧以独立进程的方式部署。
这样既达到了去中心化的目的，保障了系统的可伸缩性；也实现了服务治理和业务逻辑的解耦，二者可以独立演进不相互干扰，提升了整体架构演进的灵活性。同时服务网格架构减少了对业务逻辑的侵入性，降低了多语言支持的复杂性。
Google, IBM，Lyft 主导发起的 Istio 项目就是服务网格架构的一个典型的实现，也成为了新的现象级“网红”项目。
上图是 Istio 的架构，逻辑上分为数据平面和控制平面：
- 数据平面由一组以 sidecar 方式部署的智能代理组成，负责截获应用网络流量，收集遥测数据并且执行服务治理策略；
- 控制平面中，Galley 负责配置管理，Pilot 负责下发配置，Mixer 负责策略检查和遥测数据聚合，Citadel 负责通信中安全证书管理。
Istio 提供了一系列高阶的服务治理能力，比如：服务发现和负载均衡，渐进式交付(灰度发布)，混沌注入与分析，全链路追踪，零信任网络安全等，可以供上层业务系统将其编排到自己的 IT 架构和发布系统之中。
但是 Service Mesh 不是银弹，其架构选择是通过增加部署复杂性（sidecar）和损失性能（增加两跳），来换取架构的灵活性和系统的可演化性。
为了解决部署复杂性的挑战，社区和云服务商都在共同进行努力：
- 一方面简化服务网格自动化运维水平（比如阿里云通过 operator 大大简化了 Istio的升级运维和跨 K8s 集群部署的复杂度）；
- 另一方面提供托管的服务网格服务，帮助用户关注在业务层面的服务治理而非基础架构实现。
关于性能问题：
- 一方面 Service Mesh 需要降低自身控制平面和服务平面的性能开销，比如尽可能 offload mixer 负载，将治理策略执行下沉到数据平面完成；
- 另一方面还需要重新思考整个通信栈中应用与网络基础设施的边界。
为了实现容器应用之间的互联互通，Kubernetes 社区提出 CNI 网络模型，将容器网络连通性与底层网络实现的进行解耦，同时 K8s 提供了 Service, Ingress, Network policy 等基本元语来支持应用层的服务通信和访问控制。但是这些能力远不能满足应用对服务治理的需求。
服务网格在 L4/L7 增加了流量管理、全链路可观测性、安全互联等新功能，这些是通过引入运行在用户空间的 Envoy 代理实现的，在提升灵活性的同时也不可避免地增加了性能开销。
为了系统化解决这个问题，社区在进行有趣的探索。比如在 Cillium 容器网络中，可以利用 eBPF/XDP 等操作系统和底层网络能力，将应用层的服务控制能力（如 Kube-Proxy 提供的 service, network policy）下沉到操作系统内核和网络层解决，并优化了 Service Mesh 数据链路，减少上下文切换和数据拷贝，有效地减少了性能开销。
目前 Service Mesh 技术还处在技术成熟度曲线的初期，除了在 L4/L7 层提供灵活的服务通信功能，社区也在探索通过网络 Service Mesh[6] 实现灵活的 L2/L3 组网能力。我们相信其会成为未来企业分布式应用通信基础设施。
在这个过程中会有一些新的理念和项目被持续创造出来，我们需要能够理性地分析其业务价值和技术局限性。我们要避免将 Service Mesh 作为万灵药，不要将应用集成、应用侧安全等业务逻辑下沉到服务网格中，避免我们重蹈复杂性覆辙。可以参考 Application Safety and Correctness Cannot Be Offloaded to Istio or Any Service Mesh[7]。
回望历史
天下大势，分久必合，合久必分。企业分布式应用架构也走过一条分分合合的进化道路。在新技术迭起的今天，我们既要拥抱新技术带来的架构变化，更加要关注其背后的演进逻辑和核心价值，系统化地控制复杂性。
原文链接
本文为云栖社区原创内容，未经允许不得转载。