序文
収益性の高いクリック一方的な情報のWeb 1.0ビジネスモデルの出版社による大規模なアクセス、インターネットベースのトラフィックに2000年代初頭では、インターネットでは、ユーザー生成コンテンツとWeb 2.0ビジネスモデルによる変更をリードします。したがって、そのためのバックエンド技術アーキテクチャの急速な成長に対応するために必要なデータトラフィックとインターネットアプリケーションのボリュームとは大きな課題に直面しています。
徐々に分散アプリケーション・プロセスのより柔軟なアーキテクチャに最大1つのモノリシックなアプリケーションアーキテクチャにすべてが経験のインターネットWeb 2.0相のバックエンドアーキテクチャは、インターネットインフラの開発は、高品質と効率を追求し始めました。
スマートフォンの登場と4G規格の普及によって、PC側からのインターネットアプリケーションをすばやくより自由な移動終了になりました。したがって、モバイルデバイス、便利で簡単に見つけ、そしてので完全に旅行、オンラインショッピング、支払いおよび他のキャリーの面で生活の近代的な方法を変更しました。技術的な面では、非常に大きなクラスタサイズに対応するために、単純な分散システムは、制御が困難となって、いるので、時代--SOA、DevOpsチーム、コンテナ、CI / CDの技術的なサークルのコンセプトの発生を開き、マイクロサービス、サービスメッシュの概念別の後、ドッカー、Kubernetes、Mesos、春の雲の出現 、gRPC、Istio 他の製品、時代が本当に到着した雲をマーク。
この記事（または物品のこのシリーズは）、および他の本「ネイティブクラウドのサービスから」やって読んだ仲間の後、サム・ニューマンの「マイクロサービス、」ブック、およびその他のマイクロサービス設計関連の記事を読んだ後、自分自身をあります要約ノート。
目的は、クラウドネイティブエリアの知識の木の分散型マイクロサービスシステムを構築することです。
同時に、私たちはあなたを助けることができる学習を強化したいです。
マイクロサービスのI、
1.1マイクロサービスとは何ですか
マイクロは小さく、セルフサービスのサービスの仕事の一部です。
キーワード：小型・自治
「小」
「小」の概念は、一方ではマイクロサービスの凝集に反映しました。
- 「：結束はまた、単一の原則の機能を呼び出すことができ、一緒に集約するものと同じ理由によるばらつきが、分離何かを変更するにはさまざまな理由のために。」
- 言い換えれば、マイクロサービスは、一つのことをやってに焦点を当てるべきです。
- サービス境界によってサービスの境界を決定するために、
コードのサイズは、ライブラリーに具現一方、いくつかの標準または参照の原則があります
- チームの構造に合わせて、小さなコードベース
- すぐに書き換えるやすいように小さなコードベース
- 弁証法的ビュー。マイクロサービスアーキテクチャの小さいサービス、長所と短所は、より明白です
自治
「自治」という概念は、マイクロサービスは独立したエンティティであることを強調しました。サービス間の疎結合に反映。
- 黄金のルール：あなたは他のサービスに影響を与えることなく、サービスを変更して展開することができますか？
キーポイント：上記の2点を達成するために、正しいモデリングサービス、正しい設計サービスAPIを学ぶために。
マイクロサービスの1.2のメリット
マイクロサービスの利点のほとんどは、分散システムアーキテクチャに適用可能であり、これらの利点はマイクロサービス意志極端に
- 技術的な異質性
- 異なる技術アーキテクチャを使用して、ビジネスシナリオ、性能要件、機能要件に基づいてさまざまなサービス
- 新技術の急速な練習、技術チームの急成長
- 伸縮性/トランス脆弱性（抗脆弱性）
- サービスのダウングレード
- 災害復旧サービス、サービスヒューズ
- スプレッド
- 従来の単一のシステムでは、地元の機能を拡張するために行うことはできません
- ビジネスのニーズに応じて、特定のマイクロサービスのために拡張することが
- アーキテクチャによって、コスト削減
- 展開を簡素化
- 従来の単一アプリケーション、コードの行が変更されていても、全体的な必要性が再デプロイします。危険すぎる。
- マイクロサービスアーキテクチャ、互いに独立して展開され、各サービス
- 柔軟なバージョン作られた道
- 高速ロールバック
- 小さなリスク
- 合わせて、アーキテクチャと組織構造
- 関連知識：コンウェイの法則
- サービスの再利用可能な、組み合わせることができます
- 代替性のサービス、迅速な書き換え
1.3サービス指向アーキテクチャ
SOA（サービス指向アーキテクチャ、サービス指向アーキテクチャ）は、複数のサービスを含み、そして最終的にブレンドすることにより、サービス間の一連の機能を提供する設計手法です。独立した形で、オペレーティング・システム・プロセス中に通常存在するサービス。サービス間の通信に呼び出すには、プロセスネットワークを介して、及びないの方法で呼び出します。
XPやスクラムのようなアジャイルソフトウェア開発の特定の方法と同じとみなされ、マイクロサービスアーキテクチャは、SOAの特定の方法です。
SOAの実装上の問題が発生しました：
- 通信プロトコル（SOAPやREST）
- サードパーティ製のミドルウェアの選択
- サービスの粒度部門
- ......
思考とまとめ
「抗脆弱性（抗脆弱性）」、フォールトトレラント、独立した展開と拡大、抽象的なアーキテクチャ、テクノロジーのアイソレーション：マイクロサービスは、多くの利点を持っています。しかし、それはマイクロサービスを使用していることを言っていない、自然にこれらの特性を持っています。
例えば、抗脆弱性を持つように、我々はする必要があり、完全分散システム、非同期クリア、ネットワークセグメンテーション、ノード障害、バランスの可用性とデータの整合性の問題の不確実性を考慮してください。
同様に、我々は、保守性と拡張性を持っている必要があり、我々はまず、適切なインフラと組織構造を持っている必要があります。
理論的には、マイクロ・サービスは、開発スピードを向上させることができますが、組織が依存しているの作成、「マイクロ・サービス手数料（MicroservicePremium）」開発のスピードを低下させることができます。
したがって、マイクロサービスアーキテクチャを使用することはように、持続放出パイプラインの右、DevOpsチームとオプスチームの能力、慎重なサービスの境界を含む前提条件の数を、必要とします。また、徹底的なテストと統合モードも非常に重要です。
程度に、この最後の章では、話すこと：マイクロサービスは特効薬ではありません、あなたは、展開、テストおよび監視の面で多くの作業を行う必要があります。また、システムを拡張し、さらに同様の分散トランザクション、CAP関連の問題に対処する必要が彼らの弾力性を確保する方法を検討する必要があります。
私は自分に有利に「+コンテナ振り付けスケジューリング」クラウドプラットフォーム、マイクロサービスと併せて最大にプレーするので、クラウドへのネイティブのサービスは、トレンドである理由、これがあると思います。クラウドネイティブな知識だけでなく、背中の内容として。
偉大な神は、Martin Fowler氏の記事を読ん延長しました
マイクロサービス手数料www.martinfowler.com/bliki/Micro ...
第二に、どのようにサービスをモデル化します
あるいは、我々は2つの重要な概念、あらためて表明したいと思います高い凝集と疎結合：、対応フロントキーワード小さく、自律性を。
2.1概念
有界コンテキスト
：著者は、ここで（本は非常に読書をお勧めします）エリック・エヴァンスの本「ドメイン駆動設計」のコンセプト引用囲まれたコンテキストを。
任意の所定の境界領域は、それぞれ、外部と相互に通信する必要はなく、2つの部分に分割される（エリックは、より一般的に、それは「何か」より良くよりなければならない単語のモデルを使用）どのコンテキスト境界、複数のコンテキストを含みますその一部が必要です。各コンテキストは、それが他のコンテキストにさらされるどのモデルを決定する明確なインターフェイスを備えています。アナロジーとしてセルを使用する：「ある細胞理由を理由膜からは何の細胞内、細胞外に何を、どのような細胞膜を通る物質決定定義します。」
隠す共有モデルとモデル
同時に、共有モデルのモデルの背後にある考え方を述べました。
隠れのコンテキストアナロジーモデルとの間の相互作用は、外部モデルと対話する必要はありませんモデルモデルを共有します。
本書の観点から、マイクロサービスを開始する方法についてとTW Martin Fowler氏との視点である：「MonolithFirst」 -最初に、単一のアプリケーション。
主に以下の注意事項について：
- YAGNI原則-ソフトウェアのアイデアの有用性を決定するために、最善の方法は、簡易版を作成し、その結果を見ることです。この段階では、最も重要なことは、マイクロサービス手数料を避けるために、フィードバックサイクル原理を短縮することができますスピード、です。
- 明らかに有界コンテキストセットは -唯一の良い、安定した国境サービス、マイクロサービスが有効に機能するためにはそこにあります。しかし、正しく初めに境界を定義することは困難であることは困難よりも単量体のいずれかのマイクロアーキテクチャ、身近な地域でも、経験豊富な建築家、および最初の建物の間の機能の再構築サービス明確な機能境界の賛成で、単一のアプリケーション。
もちろん、彼らはビジネス環境であるが、それらは会社のモノマーのアプリケーションの問題場合に役立ちます、ThoughtWorksのは、他の企業がコンサルタントの問題は、それが言うことです解決の助けで、確かに素晴らしい関係で、その復興マイクロサービスアーキテクチャ。私たちは、それが理解しやすいと結論します。この業界について、このようなマイクロサービスからの直接起動など他の声が、あります。
私はこの方法であることがより傾いていますので、このように抜粋して学習。
2.2モデルのハイライト
-
時期尚早の分裂を避けます
システムが早まったマイクロサービスの価格は、特に新しい分野の顔には、非常に高いなる分割されています。多くの場合、既存のコードベースはマイクロサービスに分割されます、スクラッチマイクロサービスから開始するよりもはるかに簡単です。
-
OK有界コンテキスト
両方の共有や隠されたモデルを使用して、モジュール囲まれたコンテキストモデルを使用してください。
-
ビジネス機能からスタート
有界コンテキストを考えるとき、それはビジネス機能から開始する必要があり、あなたはまず、「それが必要とするデータの種類。」「このコンテキストはをどうするかである」を自問してから検討する必要があります
-
徐々に分割コンテキスト
次いでマイクロ境界及びサービスを考慮して、最初の比較的大きな検討、粗粒の文脈こと、とするときに適切なスロット、次いでさらにそれらのネストされたコンテキストに分割することを見つけたとき。
- ネストコンテキスト
- トップレベルのコンテキスト
思考と概要
問題空間に高い内部縫い目を達成するために結束し、低カップリングを見つける方法。有界コンテキストがこれらの継ぎ目を見つけるための非常に重要なツールであるマイクロサービスはそれらの境界と一致することで、我々は最終的なシステムが提供するマイクロサービスのすべての利点を得ることができることを確認することができます。
この部分は、DDDの哲学の本を学ぶに関連付けることができます。