-------------------------------------------------- ----------------
なぜそんなに人気がマイクロサービス？
アジャイル方法の01.出現
いわゆるアーキテクチャと管理、需要が駆動されます。
02.複数の要因が全体の機敏な力を持っている企業が必要
03.DevOps、アジャイル、クラウドにおけるマイクロネイティブアプリケーションサービス
進化する技術革新で
課題：環境の高度に分散し、異種IT運用・保守
連続配信の挑戦：3ソフトウェア開発を結合します
コードカップリング：システム全体のチームに影響を与えることができ、開発者を変更し、<20
コンポーネントレベルのカップリング：可能な、マルチチーム共同作業を実行する遅延の影響;ていないインタフェース定義、できないクロス使用技術スタックとを介して
サービスレベルのカップリング：チーム・コラボレーションの可能なマルチテクノロジー・スタック・インタフェースのための本番環境への遅延の影響現実、セルフサービスを定義します
-------------------------------------------------- ------------
マイクロサービス定義フレームワーク？
ビジネスの俊敏性を実現するために、プロジェクトの継続的なデカップリングは、複雑なシステムアーキテクチャおよび運用・保守になります
マイクロサービスとコンテナ化、エンジニアリングサポートのアジャイルの企業のために必要な選択！
一連のサービス：ビジネス機能間/シングル責任/分散化/軽量プロセス通信/独立した、独立したプロセスの展開
組織デカップリング：コンウェイの法則
コンウェイは指摘：システム設計は、組織独自の通信構造によって制限されています
第一法則：組織コミュニケーションは、システム設計によって表現されます
第二法則：時間のより多くの事を完璧にすることはできませんが、時間の最後の夜の事が常にあります
第3法則：潜在的に異種の状態特性を有する線形システムとリニア組織構造の間
第3法則：小規模な組織よりも大規模なシステムでは、常にシステムを打破する可能性が高くなります
「システム設計が組織独自の通信構造によって制限され、組織の規模が大きいほど、より悪いより多くの柔軟性が、この現象はより明白です。」
インターネットアプリケーション - ミニサービスを定義します
マイクロアーキテクチャ技術センター - >ビジネス中心のアーキテクチャ
-------------------------------------------------- ------------
進化パスソフトウェアアーキテクチャ？
アーキテクチャの進化における01.ソフトウェアのライフサイクル
探索フェーズ：全体のマッチ・ポイント製品などの製品や市場のための外観は、より多くの障害物を追加し、迅速な反復、過度の分割コマンドモジュールが必要です。より少ないチームは、共同の問題が顕著ではなく、マイクロサービスアーキテクチャには必要ありません。手動テストとベース。
拡張相：指数関数的に市場の需要。安定した主キー、モジュラーアップグレードの単一の特性を開始する機能を備えています。チームが拡大し始め、コーディネートの問題が浮上し、マイクロ分割を提供開始しました。一貫性を確保するための自動テストの導入
収穫期：製品の安定性、最大化、製品の売上高。時の安定した、各モジュールの高能力、および他の性能要件を備えています。チームの大きさは素晴らしいされている、サービスはカルバリではなく運転を継続支援するために、マイクロアーキテクチャの独立したチームでなければなりません。導入された変更のリスクを識別するためにテストを自動化。
02.ソフトウェアは、人間やロボットであります
