私が理解しているサービス化

物語のコーナー
まず物語を話します
むかしむかし(実は今ではほとんどのサイトがそうでした)、私たちは1つのサイトを作って、すべての機能コードは1つのコードライブラリの中にあって、配置する時dbは何台の機械、nginxは何台の機械、業務serverは何台の機械です.ビジネスサーバのすべてのロジックは、Webサイトのログイン、ユーザーのコメント、新しい問題、アクティビティなど、1つのプロセスにあります.
一緒に美しく見えます.
突然ある日、ボスは私达がお年玉の活动をしましょうと言って、微信のお年玉、オンラインになった后に中国人の羊毛をむしる心理状态のため、活动のページqpsは瞬时に急増して、ウェブサイトの登录のロジックqpsも急増して、活动のページは圧倒する同时に、すべてのその他の业务はすべて504で、拡容する时も全体のserverの1台1台のプラスです.拡張後、実はqpsの大きいページはこの活動だけで、容器の上の他のページはすべて資源の浪費であることが分かった.
上の現象を引き起こす問題はいくつかあります

は論理を降格し、エッジの東西がひざまずいて全局に影響を与えるべきではない(極めて核心的な論理、例えばログインしない限り)

定点拡張できない

このとき、ログインが1つのサービスであれば、自分の業務も1つのサービスと書いて、メインステーションの他の業務は動かず、ログイン、アクティビティ、メインステーション業務は機械的に配置され、アクティビティqpsが来たときはログインとアクティビティの容器を広げるだけでいいと思っていました.また、このようにアクティブなこのサービスでは、ログインのダウングレードに容易にアクセスできます.
降格とは
簡単な理解では、降格とは、降格される必要があるものがひざまずいたときに、業務が5 xxにならないことを意味します.
土のやり方はtry exceptを加えることで、次のコードでdo_somethingはmysqlの1回の書くことかもしれなくて、その他の時間の操作の1回の調べることを費やして、do_somethingが徹底的にひざまずいた時、try exceptを使って、qpsごとに来た時、do_somethingは依然として実行されます.例えばmysqlがひざまずいて起きられません.do_somethingは毎回mysqlに接続し、500にします.

    try:
        do_something()
    except Exception as ex:
        logging.error(ex, exc_info=1)

では、私たちはこの場所がひざまずいていることを知っています.どうしてずっと彼を殴っていますか.ダウングレード時に一定時間以内にデフォルト値を返して、実際にdo_をしないことができますか?something、または次の一定回数のqpsでデフォルト値を返しますか?
Hystrixのダウングレードポリシー
サービス化とは
次のコラムを見てみましょう
サービス化を知っている回答は、マイクロサービスを実施するには、どのような基礎的なフレームワークが必要ですか?これ拾ってみる
サービス化のメリットとデメリット
メリット

サービス拡張による簡単な

降格はやりやすい(サイト全体にひざまずいて他の機能が生きているとコメントできる)

オンライン時は自分の対応するサービスだけでよい、他の業務に影響しない(データ関連は影響する)

欠点

業務の分割は等級を決めて、さもなくばサービスが爆発します(機能は1つのサービスを書いて、後期のサービスはとても多いです)

データの整合性は維持しにくい.サービスを使用しない場合、トランザクションの書き込みや他の論理がデータの一貫性を維持しやすく、サービス化後にはそれが難しい(ロールバックはすべてコールサービスであり、依然として失敗する可能性がある)

不要なサービス間リクエストが増えています.サービスを使わない場合は、一度調べてコンテキストの形で伝えることができるものが多く、サービス化後はサービス内部を自分でもう一度調べる必要がある場合があります.

バッチインタフェースは

を実現することが困難である.

サービス間デカップリングは、一般にメッセージシステム(kafka)を採用し、メッセージシステムの安定性

を必要とする.

非rpc層の単測は自分をだました.結局rpcが呼び出した場所はmock

になる.
どのようにサービス化するか
業務の分割は逃れられないが、サービス化後は徐々に従来の実現に代わる必要がある.
我々は技術的手段に重点を置いている.
あなたはrestあるいはrpcを選ぶことができて、プロトコルの話HTTPのオーバーヘッドは比較的に大きくて、業界は今比較的に主流の選択はthriftプロトコルで、それからrpcをします.お腹が空いたか実装されたpythonバージョンthriftpyのセットを与えます.
だからお父さんの点は、thriftのプロトコルを手に入れたとき、例えばthriftpy、彼はdjango、ruby on railsのように非常に明確なコード階層化の要求を持っていないので、内部が規範を強制的に定義していないと、開発したサービスごとに違います.
では、サービスに複数のコンテナがある場合、どのようにしてグループ化して配置することができますか?まず、consulを発見するサービスが必要です.例えば、ユーザーサービスmemberというサービスを定義します.彼は物理機A 3001ポート、3002ポート、物理機B 3001ポートにrpc serverが3つ起きている可能性があります.consulはmemberを登録することができます.物理機ポートのことは同じように登録されています.業務側はmemberという名前を使えばいいので、具体的にどの物理機のserverを打つかを知る必要はありません.
セットで食べるのはhaproxyで負荷バランスをとるかもしれませんが、私はこれしか知らないことを示したことがありません.
本当にサービス化が必要ですか?
これはとても考えなければならない問題です.もしあなたのウェブサイトqpsが非常に低いならば、毛蛾をします.