マイクロ表現サービスのイメージ：
X軸：複数インスタンスのロードバランサ、レベルのレプリケーションを実行した後に実行されています。たとえば、クラスタのロードバランシングモードに追加される、いくつかのインスタンスを実行するために、より多くの単一のシステムよりも言います。
Y軸：さらにマイクロサービス（サブライブラリー）に分けるアプリケーションは、マイクロスプリットモードとサービスでは、トラフィックの異なる分割に基づいています。
Z軸：大量のデータ、サービス・パーティション（サブテーブル）、そのような地域別などのデータ・パーティションは、ユーザ・データ・パーティション、北京、上海、四川と他のビルドいくつかのクラスターによって要求されました。
例：ときに、このようなAのタクシーAPP、かろうじてまだ十分ではないユーザーが、その後急増、複数のクラスタを分割クラスタ。分析の後、乗客やオーナーのタクシーAPPメインユーザーことがわかりました、
アプリケーションは、3台のタクシー旅客サービス、所有者のサービス、決済サービスに分割されます。ビジネスサービスは、再び必要に応じて拡張することがあり、それぞれが三つの異なる、別のメンテナンスを備えています。
マイクロ練習のサービス：
：マイクロサービスの実用化、4点で問題に対処する必要性
（1）クライアントは、これらのサービスにアクセスする方法
各サービスのために（2）との間で通信する方法
（3）非常に多くのサービスを、どのように達成するために？
（4）サービスは、どのように解決するためにハングアップ？（バックアップ計画、緊急対応メカニズム）
1 どのようにこれらのサービスにアクセスするには、クライアント
モノリシックの道の独自開発は、すべてのサービスは、UIは、一般的に個別のJava仮想マシン上で別々に実行されている、今の別々のサービスに分割機能に応じて、直接呼び出さアップ処理することができ、ローカルです。どのようにクライアントUIを彼にアクセスするには？
背景Nのサービスがあり、フロントデスクでは、これは、特に現在のステージは、モバイルアプリケーションのための時間です、明らかに分裂当社のサービスのアイデアはありませんが、フロントデスクは再デプロイされます、アップグレード/ N管理サービス、サービスをオフライン/更新を覚えておく必要があります。ビジネスの変化の一般速いペース。
また、N小さなコールサービスは、小規模なネットワークのオーバーヘッドはありません。マイクロサービスは、ユーザーのログインおよび権限は管理が統一保守管理（OAuthの）持っているのに最適な場所は、通常ステートレス、システム内で一般的にあります。
だから、一般的背景とNのサービス・エージェントまたは一般APIゲートウェイと呼ばれるUIの間、彼の役割が含まれています：
①そのマイクロ透明のフロントデスクサービスすることを、統一されたサービスの入り口を提供
②集約サービスの背景には、トラフィックの保存、パフォーマンスを向上させます
③提供し、安全で濾過し、フロー制御管理機能のAPI
実際には、このAPIゲートウェイは、広いを達成するための多くの方法することができ、統合されたハードウェアとソフトウェアがボックスであってもよいし、それは簡単なMVCフレームワークすることができ、でも、Node.jsのは、サーバー側です。彼らの最も重要な役割は、通常は（フォアグラウンドにあります
バックオフィスサービスを提供するモバイルアプリケーションは）彼ら切り離す、サービスの統一輸出を提供し、凝集が、APIゲートウェイはまた、障害やパフォーマンスのボトルネックに単一のポイントになることがあります。
淘宝網のオープンプラットフォーム（淘宝網オープンプラットフォーム）は簡単に理解することができるようになります使用し、TAOは、APIゲートウェイがあります。
2 各サービス間の通信方法、
すべてのサービスが別の仮想マシン上で実行されているマイクロJavaプロセスから独立しているので、通信はサービス間のIPC（プロセス間通信）で、成熟した番組をたくさん持っています。今、2つの方法で最も基本的な共通：
同期呼び出し：
①REST（JAX-RS、春ブーツ）
②RPC（倹約、ダボ）
非同期メッセージ呼び出し（カフカ、通知、MetaQ）
同期および非同期の違い：
一般的な同期呼び出しは、比較的単純な、強い一貫性ですが、簡単に問題を呼び出すために、パフォーマンスが特にマルチレベルのコール時に、より悪い経験になります。RESTfulな比較とRPCにも非常に興味深いトピックです。
HTTPベースのREST一般的には、より簡単に実装し、簡単に受け入れられるように、サーバーの実装技術は、より柔軟性があり、様々な言語をサポートすることができ、かつクロスクライアント、クライアントのための特別な要件限り、HTTPのパッケージすることができします
SDKには、広く使われているので、比較的少数の、呼び出すことができるようになります。標準化と統一サービスのための統一された開発フレームワークがある場合、RPCはまた、特に家の中で、独自の利点が、より効率的で、より安全で制御可能な伝送プロトコルを持っています
いくつかのより多くの明白な彼の開発効率の利点。それは技術のそれらの蓄積、自分の選択の実際の条件に依存します。
非同期メッセージは、分散システムにおけるアプリケーションの特に広い範囲であり、彼は、サービスコールの間の結合を減少させることができるだけでなく、呼び出しの間のバッファとしての呼を確保しつつ、メッセージのバックログが、発呼者によって洗い流されないことを保証するためにパーティー
服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要 实现幂等性，因为消息
发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如果公司内部没有技术积累，
对broker分布式管理也是一个很大的挑战。
3、如此多的服务，如何实现？
在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知？服务如何管理？
这就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息
注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法， 找到一个服务，还可以将服务信息缓存在本地以提高性能。
当服务下线时，ZK会发通知给服务客户端。
客户端做：优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。
服务端做：优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。
4、服务挂了，如何解决
前面提到，Monolithic方式开发一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，
不过如果没有特别的保障，结局肯定是噩梦。所以当我们的系统是由一系列的服务调用链组成的时候，我们必须确保任一环节出问题都不至于影响整体链路。相应的手段有很多：
①重试机制
②限流
③熔断机制
④负载均衡
⑤降级（本地缓存）
这些方法基本都很明确通用，比如Netflix的Hystrix：https://github.com/Netflix/Hystrix
二.常见的设计模式和应用
有一个图非常好的总结微服务架构需要考虑的问题，包括：
1、API Gateway
2、服务间调用
3、服务发现
4、服务容错
5、服务部署
6、数据调用
6种常见的微服务架构设计模式：
1、聚合器微服务设计模式
这是一种最常见也最简单的设计模式：
聚合器调用多个服务实现应用程序所需的功能。它可以是一个简单的Web页面，将检索到的数据进行处理展示。它也可以是一个更高层次的组合微服务，对检索到的数据增加业务逻辑后进一步
发布成一个新的微服务，这符合DRY原则。另外，每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展。
2、代理微服务设计模式
这是聚合模式的一个变种，如下图所示：
在这种情况下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理可以仅仅委派请求，也可以进行数据转换工作。
3、链式微服务设计模式
这种模式在接收到请求后会产生一个经过合并的响应，如下图所示：
在这种情况下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。
因此，服务调用链不宜过长，以免客户端长时间等待。
4、分支微服务设计模式
这种模式是聚合器模式的扩展，允许同时调用两个微服务链，如下图所示：
5、数据共享微服务设计模式
自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的“单体应用（monolithic application）”时，SQL数据库反规范化可能会导致数据重复和不一致。
因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式，如下图所示：
在这种情况下，部分微服务可能会共享缓存和数据库存储。不过，这只有在两个服务之间存在强耦合关系时才可以。对于基于微服务的新建应用程序而言，这是一种反模式。
6、异步消息传递微服务设计模式
虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可能会选择使用消息队列代替REST请求/响应，如下图所示：
