現在、大規模または非常に大規模な企業のITプラットフォームは煙突システムアーキテクチャあり、その理由は、常に様々なシステムを作成するだけでなく、投資の重複のシステムの構築および保守の間の機能の重複につながり、企業内での事業展開に対応するためです。繰り返さ投資だけではなく、人間と財源だけでなく、時間を消費します。しかし、オープン煙突システム間の相互作用とコラボレーションのコストが高い、大手企業は、様々なシステム間の相互作用の問題を解決するために、ビルドのエンタープライズ・サービス・バスにESB製品を使用する必要がありました。
しかし、開発および反復的事業で、同社のビジネス構造が徐々に変化している、唯一のシステムの問題間の相互作用とコラボレーションを介して取得することは十分ではありません、徐々に戦略的、組織から企業をできるように、様々な既存のシステムを統合する必要性、こうした継続的な反復処理などのシステム、プロセスおよびサービスの観点からは、企業のビジネスモデルのニーズに応じて、現在と将来の目標を達成するために企業を可能にして、ビジネスの構造と動作モードを改善し、体系的、標準、そしてビジネスプロセスと知性を確立します企業のビジネスの青写真の反復のための情報プラットフォーム。
ただ、様々なシステム間の相互作用とコラボレーションを介して取得する十分ではない場合は、既存のシステムを統合する方法を個別にアップしているのですか？
まず、我々は援助ESBサービスインフラストラクチャの欠点の「中央」、1を分析する必要があります。この中心点を通過する必要があり、それらの間のすべてのサービスコールとサービスプロバイダとの相互作用の「集中」ESBアーキテクチャを、中心点容量があります
困難がボトルネックになるこのセンターで、その結果、拡大する;第二に：既存のシステムは、ビジネス・プロセスのオーケストレーションは、パフォーマンスのアプリケーション統合の側面は非常に良好であること、SOAのアーキテクチャに基づいて、単一のシステムであるが、業務システムの開発に複雑で、高い結合モジュールは、関連した、実際に全身に影響を与え、反復は、複雑なビジネス革新に資するものではなく、依存;第三：サービス中の繰り返し複数のシステムは、マルチコードデータが得られ、共有することはできませんされていません同期やその他の問題は、隠された危険性があります。
第二に、私たちは「中・大型ユニット、小さなフォアグラウンド」情報技術の成功例を見てください。
2015アリババグループは、台湾での戦略を立ち上げ、目標はフロントデスクフロントラインのビジネスをより機敏になるように、ある時間、革新的な、柔軟な「中・大型ユニット、小さなレセプション」のメカニズム、に沿って大規模なインターネット・データを構築することです、速く変化する市場に適用し、駅業務データ収集機能、グループ全体の製品の技術的能力、フロントオフィスのそれぞれのための強力なサポートを形成します。次のように全体的に読み取ります。
「大衆台湾は、小さなレセプション」アーキテクチャは、開発コストを削減し、研究開発の効率を向上させる、共有ビジネスサービス層、ビジネスシェアードサービスチーム、行うために別々のチームが、また、降水事業により助長に焦点を当てました。製品の障壁を破る、今のデータに共有サービスセンターを探すために持っている間のデータの従来のシステムは、統一され、標準的なデータを提供するために、サービスセンターを共有しました。チームワーク、間のシステム間の相互作用のコストを削減。巨人の肩の上。新製品の開発に関係なく、既存のもののことはすぐに、新製品、試行錯誤の低コスト、製品の革新、変化を受け入れる勇気を孵化することができ、競争がオリジナルを回復することは非常に困難であり、現在はノンストップのために競合他社の製品マネージャーの同等、前新しいアイデアを提供してくれます。持続可能な開発、累積降水量が可能な技術と運用能力。
関係「中規模および大規模のユニット、小さなレセプション」とマイクロサービス
マイクロサービスは、同様の戦略的思考を持つ分散型、分散型の自然、中規模および大規模なテーブルを反映して、戦略の具体的な実装です。既存の建築家は、このモデルから学ぶことができ、ビジネスの解決アプリケーション自体高い同時実行、高可用性、運用、保守およびその他の問題だけでなく、既存のインターネットインフラの古典を、すべての後、アリの結果はBAT、ユーバー、網易、米国のグループに加えて、実施されていますJingdongは、その他のインターネット企業は、サービスとしてのマイクロプラットフォームにもっと早く実現しています。
ユニバーサル・サービスは、1つのサービスに事業者によるサービスの零細企業、拡張された可用性、簡単、拡張開発コストを削減し、全体のサービス公開プラットフォームへの影響を軽減するためのサービスです。マイクロサービスは、企業は、このような技術の選択など、多くの問題を、検討し、ビジネス上の問題、高可用性、通信サービス、サービスの発見と管理、フォールトトレラントクラスタを分割するために必要な単一のマイクロサービスによってステアリングシステムの電源を入れ、達成するための多くの方法がある、という考えであります構成管理、データ整合性の問題、コンウェイの法則、分散型コールトレース、CI / CD、マイクロサービスのテスト、および展開のスケジューリングなど、これはいくつかの簡単なトリックではありません解決することができます。
マイクロServicesフレームワークは、ビジネスの監視と早期警戒して、台湾への1台のマシンからインフラの自動化の拡大に伴い、需要を作成して、機械の大きさを調整するために仮想化プラットフォームで異常定着機能に到達することができるので、既存の枠組みのダボ、上の必要がありますその上のサービス、発見する能力、ルーティング、負荷分散とに登録さとSpringCloud、ダボは、RPCサービスのガバナンスのフレームワーク、およびSpringCloudです。
マイクロサービスアーキテクチャが含まれています。
マイクロサービスアーキテクチャへのモノマーシステムのアップグレードに挑戦する良いサービスので、マイクロアーキテクチャ、導入されたバージョン：
1：どのように分解したりサービスへ
使用什么样的方法拆解服务？业界流行1个类=1个服务、1个方法=1个服务、2 Pizza团队、2周能重写完成等方法，但是这些都缺乏实施基础。我们必须从一些软件设计方法中寻找，面向对象和设计模式适用的问题空间是一个模块，而函数式编程的理念更多的是在代码层面的微观上起作用。
Eric Evans 的《领域驱动设计》这本书对微服务架构有很大借鉴意义，这本书提出了一个能将一个大问题空间拆解分为领域和实体之间的关系和行为的技术。目前来说，这是一个最合理的解决拆分问题的方案，透过限界上下文（Bounded Context，下文简称为BC）这个概念，我们能将实现细节封装起来，让BC都能够实现SRP（单一职责）原则。而每个微服务正是BC在实际世界的物理映射，符合BC思路的微服务互相独立松耦合。
二：失败处理的成本
随着服务的数量增加，系统失败的几率会大幅增加。
每一个服务的失败都有可能导致故障。虽然我们的目标是期望每个服务都能够互不依赖，自适应，高度容错，但是必须找到有效的方式来确保服务可用。
因此，处理失败的成本大幅增加。
三：优势资源的竞争
当有成千上万的服务时，资源如何分配？从业务角度分析，哪个服务的优先级高？哪个团队应该优先获得更优秀的资源？包括但不限于优秀的工程师、资金、软件、硬件等等。
任何时候，资源都不是免费的。
当只有几个微服务时，这些问题都不会是问题，但随着服务数量的增加，这种协作与竞争的关系会愈发明显。
四：独立性与技术债
随着微服务的大热，组织中许多人员对微服务过度追捧。
很多人认为微服务对应着松散的组织结构，只要能独立交付，团队可以做任何他们想做的。从技术角度而言，技术日新月异的变化，会产生各种大大小小的技术债，而随着采用微服务化在技术上的多样性，将变得难以维护。
微服务确实意味着自由与独立。但在大规模的组织中，过度的独立性必然带来高昂的管理与维护成本。从工程角度而言，当拥有成千上万的服务时，集中式的管控平台并不像我们认为的那样糟糕，确保大部分团队能使用相同的方式、相同的标准，能够低成本运作。
五：团队的信任危机
作为服务的交付团队的负责人，你可能有必胜的信念。充满豪情壮志，愿意带领团队遵循各种最佳实践、完美的实现所负责的服务。但是，你永远无法保证，依赖的所有上下游团队，也能按照同样的标准实现服务。这是现实。而且，随着服务关系越复杂，依赖越多，出问题的几率越大，信任危机愈发明显。
