モノリシックなアプリケーション
マイクロサービスとは異なり、別のコンセプトは伝統である「モノリシックアプリケーション」（モノリシックアプリケーション）、内部モノリシックアプリケーションは、すべての必要なサービスが含まれています。各サービスの機能モジュールは、強い結合を有する相互に依存し、それは分割と拡張することは困難です。
サイードあなたは、単一のプログラムを書かれているか、我々は正しい、意見を持っていませんでしたか？ちょうどhelloworldの機能は非常にシンプルですが、単一のプログラム、すべての機能を含むプログラムであるあなたがたHelloWorldプログラムを書くというコードを書き始める、私はあなたに栗を与えてみましょう。
アプリケーションの利点モノマー
- ソフトウェアの設計と開発計画を容易にするために、単一のプログラム内で、シンプルで機能的で、すべての開発。
- 導入が簡単、展開困難を軽減、複雑な分散クラスタ環境を展開するための単一のプログラムがありません。
- テストに簡単に、さまざまなサービス呼び出しの間には複雑な関係、内部コールは、テストに簡単です。
モノリシックなアプリケーションのデメリット
単一のプログラム開始の欠点は、特に明白ではない、プロジェクトは少ない需要を開始し、ビジネスロジックはシンプル、クール、時には書き込みコードで、クールされています。ビジネス悪夢の反復更新から、システムは、事前クールはますます大規模、なくなって無限の苦しみの反復ソフトウェアのメンテナンスと更新によって置き換えられるようになりました。
モノマーアーキテクチャ
なぜならサービスの数を置いた大型コンテナのようなモノリシックアプリケーションの、それらは拡張ユニットとして「アプリケーション」でなければならないときに、アプリケーションにつながる、不可分です。
一人で高負荷を持っているサービスモジュールは、このサービスを拡張することができないときは、リソースの追加の浪費をもたらすことができる（そう横柄される）アプリケーション全体を、拡張する必要があります。
また、モノリシックアプリケーションによるサービス間の近さに、依存性はテストの原因となる、高すぎる、アップグレードが困難であった、と開発曲線は、開発が容易ではないのでことを、後者が有意に上昇する可能性があります。これとは対照的に、「マイクロ・サービス・アーキテクチャは、」この問題を解決することができます。
マイクロサービス
マイクロサービス（Microservicesは）小さい仕事とセルフサービスです。
❝2014年、Martin Fowler氏 と ジェームズ・ルイスが 共同でマイクロサービスの概念を提案し、マイクロサービスの定義は、単一のアプリケーションに小さなサービスによって提供されているが自動にビジネス機能によって、独自の旅行や軽量取り扱い、サービスの設計を、構成しました他のサービスと通信するために配備、使用するHTTP APIへの道。同時にサービスを集中最小サイズ（例えば、使用して管理される ドッカー）機能を、サービスは異なるプログラミング言語およびデータベース・コンポーネントに実装することができます。「ウィキペディア」
❞
例えば
それとも、helloworldの会社の最高技術責任者（CTO）であることを想像し、栗を移動する前のhelloworldプログラムを取る（ボスはまだ行方不明の人？」というコードを書くLL）、世界中のあなたの会社のビジネスののhelloworld HelloWorldのバージョンを想定し、我々は異なる言語で記述する必要があります、英語、日本語、フランス語、ロシア語...そして今、世界の6,000の言語で、それぞれの出力（変な知識を加えました）。
いくつかは、これは私が使用して単純ではないと言うでしょうswitch case、私は真剣例ではありませんでした、クラスメート、逃げるために文を、実際のビジネスは、より多くのhelloworldのより複雑。次のようにまあ、私たちは言語出力により、大規模で複雑な作業であると仮定し、我々はマイクロサービスアーキテクチャを使用することができ、この時点では、アーキテクチャは次のとおりです。
マイクロサービスアーキテクチャ
マイクロサービスとSOA
「サービス指向アーキテクチャは、」 SOA (Service-Oriented Architecture) サービスとミクロのようにたくさん聞こえるが、 SOA 初期のモデルが使用されるバスだった、このバスモデルは、次のような強力なバインディング、との技術スタックです：J2EE。多くの企業では、この結果は、スイッチング時間が長すぎる、コストがあまりにも多く、新システムの収束の安定性はいくつかの時間を必要とする、最終的にはされてドッキング困難なレガシーシステムで SOA 美しく見えるが、それは、エンタープライズクラスの豪華さとなっている、中小企業は気力をくじくています。
また、実装は、SOA（例えば、SOAPなど）、通信プロトコルなど多くの問題、選択肢が発生し、どのようにサービスのサイズを決定する方法を、サードパーティのミドルウェアを選択するには、現時点では、システムを分割する方法についていくつかの指針があり、それらの多く彼らは間違っています。SOA実装のように、それは、どのように単一のマイクロサービスにアプリケーションを分割する方法を教えてくれないSOA時は、多くの問題が発生します。
まあ、マイクロサービスフレームワークの前にそれらを解決し、あなたはマイクロサービスアーキテクチャを考えることができSOA、特定の方法。
マイクロサービスアーキテクチャ
一緒に長い分、「モノリシックアプリケーション」を考慮して上記の欠点を持っている、単一のアプリケーションは、比較的単純な関数を完了するために、小さな、相互接続されたマイクロサービス、マイクロサービスの多様分割され、調整は相互に独立した状態を維持しますマイクロサービスアーキテクチャであるカップリング。
マイクロサービスの優位性
モノマー、マイクロサービスに関するサービスは多くの利点があり、ここではいくつかのキーの利点があります
技術的な異質性
異なる内部技術サービスの開発が一致しないことができ、あなたは、HelloWorldサービスAを開発するためにJavaを使用することができ、helloworldのサービスBを開発するgolangで、私たちはもはや、言語の種類を持っていない世界最高の言語の議論です。
選択した技術やサービスに最も適したさまざまなサービスが、システムがストアのRedisに選択することができ、このようなAサービスなど、さまざまなストレージ技術のさまざまな部分で使用することができ、Bは、あなたは、許可されているサービスMySQLのストレージを使用するサービスを選択することができますあなたはショットを呼び出します。
隔離
各サービスは独立した自律システムであるため、サービスは、また麻痺している別のサービスにつながることはありません使用できません。それは、もちろん、プログラムは単一のバックアップアプリケーション内の別のマシンで同じプログラムをモノマー展開することができ、単一のアプリケーション・モジュールの麻痺で、不可能で、システム全体が利用できない原因になりますしかし、また、資源問題の言った廃棄物の上にあります。
スケーラビリティ
単一の大規模なサービスのパフォーマンスのボトルネックが全体としてのみソフトウェアに拡張することができれば、本当にただの小さなモジュールのパフォーマンスに影響を与えることができ、我々はまた、アプリケーション全体のアップグレードの費用を支払わなければなりませんでした。改善マイクロサービスアーキテクチャにおけるこの結果は、あなただけのアップグレードは、サービスのパフォーマンスに影響を与えるものに拡張することができないので、効果が良い救済策です。
簡素化の展開
あなたのサービスは、大規模な単一のサービスである場合には、数行のコードは明らかに非常に複雑であり、アプリケーション全体を、再コンパイルする必要があり、変更、およびソフトウェアがもたらした不確実性が非常に高い変化しても、数百万行のコードがありますソフトウェア導入の影響も非常に大きいです。マイクロサービスアーキテクチャでは、それが問題である場合は、各サービスの展開が独立しており、唯一の単一のサービスに影響を与え、あなたはすぐにロールバックバージョンは解決することができます。
簡単に最適化
、すべての後に、コードの小さなコード手段の量より制御影響はによってもたらされた変化し、単一のサービスは、あなたがリファクタリングする必要があるか、サービスのこの部分を最適化するとき、それははるかに簡単になるように、素晴らしいことではないだろうコードの量のマイクロサービスアーキテクチャ。
マイクロサービスの欠点
当社のマイクロ上記サービスのメリットを強調してきた、しかし、マイクロ・サービス・アーキテクチャは万能薬ではない、すべての問題を解決することはできませんが、実際には、これはいわゆるマルチ手の男に多くの小さな単一の分散サービスのリードに分割するマイクロサービスアプリケーションです雑多な、悪いサービスの問題乗算管理が来ました。
マイクロサービスの欠点に対処するためには、高齢者は、次の概念を提案しました。
サービスの登録と発見
「サービス発見」機能と呼ばれている正しいターゲットサービスのアドレス多くのマイクロサービスを、見つける方法を、マイクロビジネス機能間の総合的なサービスを完了するために、お互いを呼び出します。
共通プラクティスは、サービスプロバイダーがそれらのアドレスは、「サービスレジストリ」に報告入れたときに開始する「サービスレジストリ。」サービス「サブスクリプション」サービスの変更「通知」、彼ができるサービスに直接見た後プッシュサービスアドレスリストを受信するための動的サービスレジストリへの発信者。
サービス検出
サービス監視
運用および監視プログラムモノマー、良く言った、大規模なマイクロサービスアーキテクチャ、運用・保守サービスの維持が大きな課題です。サービス運用、保守要員がサービス操作のリアルタイムステータスのさまざまなを習得する必要があり、それがサービスのメモリ使用量、コール情報、健康状態の数を確認するには、コントロールパネルを持っていることが最善です。
これは、トポロジ、モニター（メトリック）を含む包括的なサービス監視システムを、持っている（ログ）、コール・トレース（トレース）、アラーム通知、健康チェックや他の予防措置を監視ログに記録する私たちを必要とします。
フォールトトレラントサービス
任意のサービスエンジニアが行うことができ、何の問題は、複雑で変化する環境の生産、サービス、障害の様々な（など、ダウンタイム、過負荷など）を実行されていない、必然的に発生し、100％を保証することはできませんが、障害が発生した場合に影響を最小限に抑えることです可能な限り迅速に通常のサービスを回復する範囲。
プログラマ天国は「ヒューズ、隔離、電流制限および格下げ、タイムアウトメカニズムを、」導入する必要性を回避するために、この目的のために、このような「フォールトトレラントサービス」メカニズムとして継続的なサービスの可用性を確保します。
セキュリティサービス
一部のサービスは、機密データのセキュリティ問題を存在し、「セキュリティサービスは、」認証メカニズムを使用して機密サービスを確保することで、サービスへのアクセスは、データ漏洩のリスクを防ぐために、適切な認証と承認を必要とし、セキュリティは永久トピックですマイクロサービスもやるべき仕事がたくさんあります。
サービス管理
「ガバナンス」といえば、一般的に唯一の治療を必要とする問題があり、我々は通常、環境経営を言う、公害防止は、より多くのマイクロサービスアーキテクチャのマイクロサービスを意味し、問題は上記マイクロを解決するために、上記のものとより明らかですサービスアーキテクチャの欠陥「サービス管理」が登場します。
これらの問題はない大手企業が技術チームを成熟している場合、非常に大きな頭と推定され、自分の言葉を解決するためにマイクロサービス会社の技術チームでなければなりません。幸いなことに、巨人の肩は、私たちはの導入により、サービス管理を完成助けるために、私たちを貸して立ち上がることができますがあり、「マイクロ・サービスフレームワーク。」
マイクロサービスフレームワーク
業界の成熟したマイクロサービスフレームワークの一部を紹介します。
ダボ
alibabaのオープンソースアプリケーションがRPCのパフォーマンスを介して出力と入力機能とサービスを実現することができ、それはシームレススプリングフレームワークと統合することができるように、高性能のJava優れたサービス・フレームワークです。リモートメソッド呼び出しのためのインターフェース、インテリジェントなフォールトトレランスと負荷分散、および自動登録およびサービスの発見：Apacheのダボ| |dʌbəʊは、高性能、3つのコア機能を提供する軽量なオープンソースのJava RPCフレームワークです。2011年の外国オープンソースの終わりには、唯一のJava言語をサポートしています。
公式サイト：http://dubbo.apache.org/zh-cn/
ダボチャート|ソースdubbo.apache.org
タール
マイクロサービスアーキテクチャTAF（合計アプリケーションフレームワークは）練習の年の結果は、オープンソースプロジェクトテンセント内部使用を作っまとめました。のみも広く使用され、現在、内部テンセントで、C ++言語をサポートしています。2017年の外国収益は、唯一のC ++言語をサポートしています。
出典： https://github.com/TarsCloud/Tars/
TARSチャート|ソースgithub.com/TarsCloud
バックエンド技術学校タールは、「GET「返信」「タール出生ガチョウの工場PPTプレゼンテーションフレームワークでは、学生が自分のパブリック数で、トラブルに自分自身を見つけるしたくない、ダウンロードされています」。"
Tomcatの
Weiboは、Javaのオープンソースのフレームワークです。Motanは広くサービスコールの数百にほぼ千億毎日完了し、マイクロブログのプラットフォームで使用されてきました。2016年の外国収益は、唯一のJava言語をサポートしています。
公式ガイド： https://github.com/weibocom/motan/wiki/zh_userguide
Motanフレームワーク|ソースgithub.com/weibocom/motan
gRPC
Googleがプロトコル開発のベースいるProtobuf（プロトコルバッファ）配列を設計した高性能の開発であり、汎用のオープンRPCフレームワーク、主にGoogleが開発したモバイルアプリケーションのため及びHTTP / 2標準プロトコルに基づきます。それ自体では、分散されていないので、上記ニーズさらなる開発の機能的枠組みを達成します。複数の言語をサポートしている2015年の外国オープンソースのクロス言語のRPCフレームワーク。
中国のチュートリアル：https://doc.oschina.net/grpc?t=58008
gRPCチャート|ソースwww.grpc.io
倹約
RPC gRPC、スリフトも独自のインタフェース定義言語IDLを持つことになりますように、Apacheのオープンソースプロジェクトの一つとなった、アパッチ財団に貢献した2007年のFacebookの言語によって開発された内部システム間での最初の高性能フレームワークで、コード生成を通じて、クライアントサーバーとSDK、複数言語のサポートの終了コードを生成するプログラミング言語の多様。
倹約アーキテクチャ|ソースウィキメディア
マイクロサービスフレームワークとRPC
多くの人々は、我々はその後、RPCの概念を見て、少し我々は言っサービスフレームワーク上で、これら二つの概念を少し混乱します。
RPCとは何ですか
RPC (Remote Procedure Call)リモート・プロシージャ・コールは、コンピュータの通信プロトコルです。私たちの通常の手順では、ローカル呼び出しプログラム内で呼び出すことであるRPCあなたが別のネットワーク通信の中間が参加するプログラム、およびプロセス間通信を呼び出すために、同じ機能のようなローカル関数を呼び出すことができますが、あなたは、実装の詳細を知る必要はありません、RPCあなたのブロックのためのフレームワーク基本となる実装。RPCサーバです-古典を介して達成され、クライアント（クライアント/サーバー）モード- 「応答受け入れる送信要求」情報交換のシステムを。
両者の関係
RPCそして、私の理解のマイクロサービスフレームワークとの間の関係は、マイクロサービスフレームワークは、一般的に含まRPC実装と「サービス管理」機能のシリーズを、ソフトウェア開発フレームワークです。私たちは、フレームワークが提供する「サービス管理」マイクロサービス機能の使用を容易にするために、独自のマイクロサービスに基づいて、このフレームワークを実装することができRPC能力、また、いくつかの人々に呼ばれるので、マイクロサービスフレームワークRPC框架。
次世代マイクロアーキテクチャサービス
Service Mesh（サービスグリッド）は、次世代のマイクロサービスアーキテクチャであると考えられているService Mesh私たちに新しい機能を持っていなかった、他のツールを解決するために使用されているサービスのネットワーク呼び出し、電流制限、ヒューズおよび監視やその他の問題を解決してきたが、これは、ある 環境で実現。Cloud Nativekubernetes
機能
サービスメッシュは、次の特性があります。
- アプリケーション間の通信の中間層
- 軽量ネットワークエージェント
- 無対応アプリケーション
- 再試行は、アプリケーション/残業をデカップリング監視、追跡、およびサービスの発見
現在、2つの人気 Service Mesh のオープンソースソフトウェア [Istio](https://istio.io/) と [Linkerd](https://linkerd.io/)直接することができkubernetes た、統合Linkerdになってきた云原生计算基金会 CNCF (Cloud Native Computing Foundation) メンバー。
なぜサービスメッシュ
なぜ質問既存のマイクロサービスアーキテクチャは、によって解決されている必要がありService Mesh、その後？これは良い質問です。
質問に答える前に、見下すistio.ioする上でservice mesh私は非常に良い、抜粋を感じる、説明します。
❝サービスメッシュのサイズと複雑さに成長するにつれて、それは理解し、管理することが困難になることができます。その要件は、発見、負荷分散、障害回復、メトリクス、および監視を含めることができます。サービスは、多くの場合、また、メッシュA / Bテスト、カナリアロールアウト、レート制限、アクセス制御、およびエンドツーエンドの認証のような、より複雑な運用上の要件を持っています。
それは簡単にサービスコードにいくつかまたはコードの変更なしで**、負荷分散、サービス・ツー・サービス認証、監視、およびより多くので展開されたサービスのネットワークを作成することができます。**
❞
総括するようにしてください：マイクロサービス増加の複雑化により、管理がより困難になる、マイクロ・サービス・アーキテクチャは、「ネットワーク呼び出し、電流制限、ヒューズおよび監視」やその他の問題が、ほとんどのフレームワークやオープンソースソフトウェアを解決既存のビジネスは、侵入式ビジネス・サービス・プログラムの該当する「サービス管理」コンポーネントを統合する必要があります。
Service Meshマイクロサービスは、としてTCP/IP、インターネットにあるTCP/IPネットワーク通信のための輻輳制御、接続指向の、信頼性の高い、バイトストリーム通信機能に基づいてを提供し、あなたは、根本的な再送信、パリティ気にフロー制御をする必要はありません。
使用Service Meshあなたが「サービス管理」の詳細を心配する必要はありませんを超えて、すべてのビジネス機能により、特別なサービス変換を行う必要はありませんService Mesh助けにあなたがそれを行います。それは次のようである轻量级网络代理 右のアプリケーションは、透明、それを介してすべてのアプリケーション間で流れますので、アプリケーショントラフィックの制御が可能になりそう serivce mesh な実装。
サービスメッシュアーキテクチャ|写真：パターン：サービスメッシュ
最後に書かれました
ITの世界ではどのような技術は、時代を超越していることは、その後、単一のプログラムからのマイクロサービスアーキテクチャに、マイクロサービスアーキテクチャの進化の例ではなく、service mesh次の反復技術的なポイントは、ときここでアーキテクチャは、私は知らないが、私はマイクロ知っています間違いなく更新するサービスアーキテクチャは、ITの人々は、生涯学習の習慣を確立する必要があります。
さらに重要なことは、私は私が励起された見たとき、心のOSがあり、技術のための情熱を持っている抱擁変化に対する熱、新しい技術を取り入れ、新しい技術です厉害了，还能这么玩！、私はプログラミングの賃金のために、あなたがそのような情熱を持っていないと思い、人生は多くの楽しみになります。
古いルール。記事の目的は明白な欠陥がテキストで表示された場合、私は、精度の最大の程度を確保するために確認を繰り返すことになる技術情報が一緒に我々が調査し学ぶことも歓迎され、知識の共有理解に、お読みいただきありがとうございました。