マイクロサービスシリーズ-転写:マイクロサービスについて話していますが、マイクロサービスの逆パターンと罠は何ですか(二)
マイクロサービスについて話していますが、マイクロサービスの逆モードと罠は何ですか(二)マイクロサービスについて話しています.マイクロサービスの逆モードと陥没井戸は何ですか(一)http://www.jianshu.com/p/3986239138fehttps://www.jianshu.com/p/c76f7f234a31
六、理由のない開発者の罠の名前はジェームズ・ディーンが演じた映画「理由のない反逆」(Rebel Without a Cause)から来て、ある問題の青年が間違った原因で間違った決定をした.
多くのアーキテクチャエンジニアと開発者は、サービスの粒度やメンテナンスツールなどのマイクロサービスの開発でメリットとデメリットを比較していますが、エラーの原因に基づいて、エラーの決定をしました.
6.1誤った決定図6-1は、テストによってサービス区分が細すぎることが判明したため、性能に非常に影響し、主にサービス区分が細すぎるため、通信作業量が増加し、安定性にある程度影響を及ぼすことを説明している.この場合、開発者またはアーキテクチャは、パフォーマンスと信頼性の問題を解決するために、これらのサービスをより粗いサービスに統合することを決定します.
図6-1
この案は合理的に見えるが、その後の配置、変更制御、テストに影響を与える.
さらに図6−2を見ると、左側のサービスが太すぎて、サービスのテストと配置に影響を及ぼし、分割が行われ、各サービスの範囲が減少する.
図6-2
以上の2つのシナリオから、サービスが細すぎると、サービスを統合することを考慮する必要があります.サービスが太すぎると、サービスを分割することも考慮します.細すぎると通信コストが増加し、信頼性が不安定になりやすく、粗すぎるとテストやオンライン署名が困難になるので、メリットとデメリットをどのように比較するかによって異なります.
6.2ビジネス・ドライバを理解ビジネス・ドライバを理解することは、マイクロ・サービスの合理的な設計にとって極めて重要であり、各アーキテクチャまたは開発者は、まず次の3つの質問に答える必要があります.
なぜマイクロサービスアーキテクチャを設計するのですか?主なビジネス駆動は何ですか?最も重要なアーキテクチャの特徴は何ですか?主なアーキテクチャ特性として、ブランチ、パフォーマンス、堅牢性、拡張性を使用して、ビジネスをどのように利用してサービスの統合と分割を行うかを最初に考慮する必要があります.
シーン1:マイクロサービスへの移行は主に高速オンラインと布署を達成したい
このようなシナリオでは、サービスの配置能力は、パフォーマンス、安定性の要因よりも相対的に大きいため、サービスを分割する際には、わずかな細粒度を考慮することができる.
シーン2:マイクロサービスへの移行は主にシステムのパフォーマンスと堅牢性を向上させたい
このシナリオは、単一のアプリケーションからマイクロサービスアーキテクチャへの移行の一般的な要因であり、多くの企業がビジネス駆動であるため、サービスの信頼性と堅牢性を考慮する必要があるため、細粒度のサービスではなく、より粗い粒度のサービスに傾いている.
私がよく使う方法の1つは、図6-3に示すように、サービス粒度の区分問題があるたびに、私たちはよく白板で下書きをして議論します.
図6-3
七、流行の罠を追うには、マイクロサービスを抱擁しなければなりません.これは現在の傾向であり、他の人や会社は現在このようにしています.
私たちは盲目的にマイクロサービスを使用していますが、ビジネスニーズ、組織構造、技術環境を詳しく分析していません.これは、ストリーミングの罠です.
この罠を避ける方法はマイクロサービスのメリットと短所を十分に理解しており、俗説では、自分を知って彼を知っていて、百戦危うくないと言われています.
7.1マイクロサービスの長所と短所:
パブリッシュ:テストのパブリッシュが容易:変更制御のテストが容易:サービスの機能モジュールの規模を変更しやすく、欠点を拡張できます.
Team組織は性能の信頼性を変えて運行とメンテナンスの難易度を下げる7.2他のアーキテクチャモデルのマイクロサービスのアーキテクチャはとても良いですが、唯一のアーキテクチャモデルではありませんか.例えば、以下に他のアーキテクチャモデルがあります.
Services-Based ArchitectureServices-O r i ented ArchitectureLayered ArchitectureMicrockernel ArchitectureSpace-Based ArchitectureEvent-driven ArchitecturePipeline ArchitecturePipeline Architectureもちろん、システム内でこれらのアーキテクチャモードを混在させることはありません.
以下にアーキテクチャの参考資料を示します.Software Architecture Fundamentals:U nderstanding the BasicsSoftware Architecture Fundamentals:Beyond the BasicsSoftware Architecture Fundamentals:Services-Based Architecture Software Architecture PatternsMicroservices vs.Services-Oriented Architecture
八、静的契約トラップはマイクロサービスの消費者とプロバイダの間に契約を提供し、契約は主にデータの入力と出力、および操作の名称を含み、契約は通常XML、JSONまたはJAVAオブジェクトなどで表される.しかし、これらの契約は永遠に変わらないのだろうか.
ここでは、サービス契約のバージョン管理に起因する問題を例に挙げて説明します.サービスが3つの異なるクライアントからアクセスされている場合(client 1、client 2、client 3)、client 1がサービス契約を変更したい場合は、client 2とclient 3がこの変更に適応できるかどうかを確認し、client 2とclient 3がこの変更に適応できないことを教えてくれます.調整が完了するまで数週間かかります.この場合、client 1、client 2、client 3は調整完了に適応するのに数週間かかるが、client 1はこんなに長い時間待つことができないことを伝える必要がある.
あなたのサービス契約でバージョン管理を提供し、後方互換性を実現することができます.クライアントt 1の要求に従って柔軟な制御を行うことができ、v 1.1のような新しいバージョンの契約を作成することができます.client 2とclient 3は依然としてv 1バージョンを使用しています.これにより、client 1はすぐに契約として変更することができ、client 2とclient 3が調整の時間に適応する必要はありません.
ヘッダーにバージョン番号を追加するか、契約自体のschemeにバージョン番号を追加するかの2つの実装方法があります.
8.1ヘッダバージョン制御契約バージョンの第1の方法は、図8−1に示すように、リモートアクセスプロトコルヘッダにバージョン番号を配置することであり、リモートアクセスプロトコルには、REST、SOAP、AMQP、JMS、MSMQなどが含まれる.
図8-1
例えば、RESTを使用する場合、以下のコードのように、MIMEタイプを使用してプロトコルバージョンを指定できます.
POST/trade/buyAccept:アプリケーション/vnd.svc.trade.v 2+jsonヘッダのMIMEタイプに契約バージョン番号を指定することで、サービス側はヘッダのMINEタイプ解析で対応するバージョン番号を得ることができる.
8.2 Schemaバージョン管理第2のバージョン管理方式は、図8-2に示すように、ヘッダにバージョン番号を指定する必要がない契約自体で行われる.
図8-2
まず、次のjson形式のデータを見てください.
{"$schema": "http://json-schema.org/draft-04/schema#","properties":{"version":{"type":"integer"},"acct":{"type":""number"},"cusip":{"type":""string"},"sedol":{"type":""string","shares":{"type","number","minimum":100},"required":["version","acct","shares"]}このモードは、契約の入力データにバージョン番号を直接定義します.このモードの最大の利点は,プロトコルに関係なく,データフォーマットのみに関係することである.
POST/trade/buyAccept: application/json{ "version": "2","acct": "12345","sedol": "2046251","shares": "1000"}
この方式では、毎回メッセージデータを解析し、出版番号を抽出して検証する必要があり、データフォーマットが変わる可能性もあり、JAVAオブジェクトへの自動マッピングが容易ではないという欠点もあります.
六、理由のない開発者の罠の名前はジェームズ・ディーンが演じた映画「理由のない反逆」(Rebel Without a Cause)から来て、ある問題の青年が間違った原因で間違った決定をした.
多くのアーキテクチャエンジニアと開発者は、サービスの粒度やメンテナンスツールなどのマイクロサービスの開発でメリットとデメリットを比較していますが、エラーの原因に基づいて、エラーの決定をしました.
6.1誤った決定図6-1は、テストによってサービス区分が細すぎることが判明したため、性能に非常に影響し、主にサービス区分が細すぎるため、通信作業量が増加し、安定性にある程度影響を及ぼすことを説明している.この場合、開発者またはアーキテクチャは、パフォーマンスと信頼性の問題を解決するために、これらのサービスをより粗いサービスに統合することを決定します.
図6-1
この案は合理的に見えるが、その後の配置、変更制御、テストに影響を与える.
さらに図6−2を見ると、左側のサービスが太すぎて、サービスのテストと配置に影響を及ぼし、分割が行われ、各サービスの範囲が減少する.
図6-2
以上の2つのシナリオから、サービスが細すぎると、サービスを統合することを考慮する必要があります.サービスが太すぎると、サービスを分割することも考慮します.細すぎると通信コストが増加し、信頼性が不安定になりやすく、粗すぎるとテストやオンライン署名が困難になるので、メリットとデメリットをどのように比較するかによって異なります.
6.2ビジネス・ドライバを理解ビジネス・ドライバを理解することは、マイクロ・サービスの合理的な設計にとって極めて重要であり、各アーキテクチャまたは開発者は、まず次の3つの質問に答える必要があります.
なぜマイクロサービスアーキテクチャを設計するのですか?主なビジネス駆動は何ですか?最も重要なアーキテクチャの特徴は何ですか?主なアーキテクチャ特性として、ブランチ、パフォーマンス、堅牢性、拡張性を使用して、ビジネスをどのように利用してサービスの統合と分割を行うかを最初に考慮する必要があります.
シーン1:マイクロサービスへの移行は主に高速オンラインと布署を達成したい
このようなシナリオでは、サービスの配置能力は、パフォーマンス、安定性の要因よりも相対的に大きいため、サービスを分割する際には、わずかな細粒度を考慮することができる.
シーン2:マイクロサービスへの移行は主にシステムのパフォーマンスと堅牢性を向上させたい
このシナリオは、単一のアプリケーションからマイクロサービスアーキテクチャへの移行の一般的な要因であり、多くの企業がビジネス駆動であるため、サービスの信頼性と堅牢性を考慮する必要があるため、細粒度のサービスではなく、より粗い粒度のサービスに傾いている.
私がよく使う方法の1つは、図6-3に示すように、サービス粒度の区分問題があるたびに、私たちはよく白板で下書きをして議論します.
図6-3
七、流行の罠を追うには、マイクロサービスを抱擁しなければなりません.これは現在の傾向であり、他の人や会社は現在このようにしています.
私たちは盲目的にマイクロサービスを使用していますが、ビジネスニーズ、組織構造、技術環境を詳しく分析していません.これは、ストリーミングの罠です.
この罠を避ける方法はマイクロサービスのメリットと短所を十分に理解しており、俗説では、自分を知って彼を知っていて、百戦危うくないと言われています.
7.1マイクロサービスの長所と短所:
パブリッシュ:テストのパブリッシュが容易:変更制御のテストが容易:サービスの機能モジュールの規模を変更しやすく、欠点を拡張できます.
Team組織は性能の信頼性を変えて運行とメンテナンスの難易度を下げる7.2他のアーキテクチャモデルのマイクロサービスのアーキテクチャはとても良いですが、唯一のアーキテクチャモデルではありませんか.例えば、以下に他のアーキテクチャモデルがあります.
Services-Based ArchitectureServices-O r i ented ArchitectureLayered ArchitectureMicrockernel ArchitectureSpace-Based ArchitectureEvent-driven ArchitecturePipeline ArchitecturePipeline Architectureもちろん、システム内でこれらのアーキテクチャモードを混在させることはありません.
以下にアーキテクチャの参考資料を示します.Software Architecture Fundamentals:U nderstanding the BasicsSoftware Architecture Fundamentals:Beyond the BasicsSoftware Architecture Fundamentals:Services-Based Architecture Software Architecture PatternsMicroservices vs.Services-Oriented Architecture
八、静的契約トラップはマイクロサービスの消費者とプロバイダの間に契約を提供し、契約は主にデータの入力と出力、および操作の名称を含み、契約は通常XML、JSONまたはJAVAオブジェクトなどで表される.しかし、これらの契約は永遠に変わらないのだろうか.
ここでは、サービス契約のバージョン管理に起因する問題を例に挙げて説明します.サービスが3つの異なるクライアントからアクセスされている場合(client 1、client 2、client 3)、client 1がサービス契約を変更したい場合は、client 2とclient 3がこの変更に適応できるかどうかを確認し、client 2とclient 3がこの変更に適応できないことを教えてくれます.調整が完了するまで数週間かかります.この場合、client 1、client 2、client 3は調整完了に適応するのに数週間かかるが、client 1はこんなに長い時間待つことができないことを伝える必要がある.
あなたのサービス契約でバージョン管理を提供し、後方互換性を実現することができます.クライアントt 1の要求に従って柔軟な制御を行うことができ、v 1.1のような新しいバージョンの契約を作成することができます.client 2とclient 3は依然としてv 1バージョンを使用しています.これにより、client 1はすぐに契約として変更することができ、client 2とclient 3が調整の時間に適応する必要はありません.
ヘッダーにバージョン番号を追加するか、契約自体のschemeにバージョン番号を追加するかの2つの実装方法があります.
8.1ヘッダバージョン制御契約バージョンの第1の方法は、図8−1に示すように、リモートアクセスプロトコルヘッダにバージョン番号を配置することであり、リモートアクセスプロトコルには、REST、SOAP、AMQP、JMS、MSMQなどが含まれる.
図8-1
例えば、RESTを使用する場合、以下のコードのように、MIMEタイプを使用してプロトコルバージョンを指定できます.
POST/trade/buyAccept:アプリケーション/vnd.svc.trade.v 2+jsonヘッダのMIMEタイプに契約バージョン番号を指定することで、サービス側はヘッダのMINEタイプ解析で対応するバージョン番号を得ることができる.
8.2 Schemaバージョン管理第2のバージョン管理方式は、図8-2に示すように、ヘッダにバージョン番号を指定する必要がない契約自体で行われる.
図8-2
まず、次のjson形式のデータを見てください.
{"$schema": "http://json-schema.org/draft-04/schema#","properties":{"version":{"type":"integer"},"acct":{"type":""number"},"cusip":{"type":""string"},"sedol":{"type":""string","shares":{"type","number","minimum":100},"required":["version","acct","shares"]}このモードは、契約の入力データにバージョン番号を直接定義します.このモードの最大の利点は,プロトコルに関係なく,データフォーマットのみに関係することである.
POST/trade/buyAccept: application/json{ "version": "2","acct": "12345","sedol": "2046251","shares": "1000"}
String msg = createJSON(
"version","2",
"acct","12345",
"sedol","2046251",
"shares","1000")};
jmsContext.createProducer().send(queue, msg);この方式では、毎回メッセージデータを解析し、出版番号を抽出して検証する必要があり、データフォーマットが変わる可能性もあり、JAVAオブジェクトへの自動マッピングが容易ではないという欠点もあります.