[-01]アーキテクチャ復刻：マイクロサービスアーキテクチャ
いいえ公共の純粋な笑顔の記事ません：[12]私はマイクロサービスアーキテクチャを描く手に従ってください！
マイクロサービスとは何ですか？
マイクロ・サービス・アーキテクチャは、アーキテクチャパターンや建築様式の一種である、それは同様のサービス、協調、間の協調、独自の独立したプロセスを実行している各、小さな一連のサービスに単一のアプリケーションを提唱します究極の価値をユーザーに提供します。
（通常はHTTPベースのRESTful API）互いに通信するサービスとの間の軽量の通信メカニズムを使用します。各ビルドに固有のビジネスの周りのサービス、および独立して生産環境、生産のような環境にし、その上に展開することができます。
また、あなたは非常に軽量な集中管理を持つことができ、それらを構築するために、ツールを適切な言語を選択し、ビジネス・コンテキストに基づいている必要があり、特定のサービスのための統一、集中サービス管理メカニズムを回避しようとする必要がありますこれらのサービスを調整します。あなたが別のデータストレージを使用することができ、サービスを記述するために別の言語を使用することができます。
Martin Fowler氏の説明によると、私は次のポイントをまとめました。
①小さなサービス
小さなサービス、ない特定の基準や規範が、彼は全体の仕様にあったが小さくなければなりません。
②独立したプロセス
別のサービスが桟橋上で実行中のサービスの各セットは、私は、Tomcatコンテナにこのサービスを実行することが、独立して実行されています。プロセスを通じてウェイは、我々は全体のサービスを拡張し続けています。
③通信
過去の契約はサービスがお互いを呼び出す過去賢くよりも軽い意味SOAP、光通信、などのESB、のように、それはスマートなエンドポイントおよびダム、パイプ、いわゆるで、重いです。
これらは、エンドポイントを分離されて、完全なビジネスコミュニケーションは、これらのマイクロサービスは、コマンド神経質パイプライン事業の一連のLinuxシステムのように張ら呼び出します。
過去の事業、我々は通常、システムをもたらす結合を検討し、依存関係の多様性を考慮してください。開発者はビジネスロジックの開発に集中することを可能にするマイクロサービス。
④展開
より独立しているように、ビジネスよりも、独立して展開する必要があります。しかし、これはまた、従来の開発プロセスは一定の責任を持つべき操作やメンテナンスのために開発された変更のある程度、になることを意味します。
⑤管理
従来のエンタープライズSOAのサービスは、高結合、管理が大きな困難になる傾向があり、チーム開発コストは比較的大きいです。
各チームは、異なるサービスを実現するための技術の彼らの政府の選択は、そのビジネス・ロジックを実現するために、彼らのニーズに応じて異なるテクノロジー・スタックを選択するかもしれないと思うことを可能にするマイクロサービス。
マイクロサービスのメリットとデメリット
なぜマイクロサービス？楽しみのために？そうではありません。ここで私は、ネットワーク上の利点から、より完全な回答を見つけることです。
-
利点は、各サービスに凝集十分である十分に小さい場合、コードは、容易にこのような特定のビジネス機能またはサービス要件と理解集束させることができます。
-
シンプルの開発、開発効率を向上させるには、ひたむきなサービスは一つだけのことを行うことがあります。
-
マイクロサービス小さなチームが別々に開発することができ、この小さなチームは2-5人の開発スタッフです。
-
マイクロサービスが疎結合され、サービスの機能的意義は、それが開発段階や展開の段階で独立しているかどうか、そこにあります。
-
マイクロサービスは、異なる言語の開発を使用することができます。
-
使いやすさとサードパーティの統合、マイクロサービスは、ジェンキンス、ハドソン、竹のように継続的インテグレーションツールを通じて、自動展開を統合するための簡単かつ柔軟な方法を可能にします。
-
マイクロサービスを簡単に修正し、維持、開発者が理解し、このような小さなチームは、より自分の仕事の成果を心配することができます。協力の価値を反映する必要はありません。マイクロサービスは、最新技術の統合の利点を取ることができます。
-
マイクロサービスは、単なるビジネス・ロジック・コードで、HTML、CSS、または他のインタフェースコンポーネントが混在していません。
-
各サービスは、独自のマイクロ記憶容量を有し、独自のデータベースを持つことができ、あなたが統一されたデータベースを持つことができます。
一般に、マイクロサービスの利点は、大規模システムの顔は、効果的に明確にするサービスロジックアーキテクチャの複雑さを減らすことができるということです。
しかし、それはまた、このような分散環境での一貫性に関するデータ、テストの複雑さ、運用・保守の複雑さなどの問題の多くをもたらすでしょう。
利点、欠点のすべての種類とマイクロサービス、そしてサービスのためのマイクロ組織の使用は何ですか？
①マーフィーの法則（システム設計）とコンウェイの法則（システム・パーティショニング）
コンウェイの法則は、50年以上前である前方マイクロサービスの概念を入れました。この記事コンウェイ、最も有名な言葉で：
設計システムは、これらの組織の通信構造のコピーであるデザインを生成するために制約されている組織。
中国の通訳はおそらく意味：システム設計組織は、そのデザインは、組織内の同等の生産、組織間の通信構造。
下の絵を見て、その後、Appleの製品は、マイクロソフトの製品設計について考え、鮮やかにはこの文を理解することができます。
②アーキテクチャの進化
アーキテクチャは、マイクロサービスのアウト進化している、あまりにも、とき大手テクノロジー企業から、ある程度大規模では、完全に進化したテクノロジーアーキテクチャシステムは、管理が必要です。
伝統的なチーム、そして、企画、見終えた開発計画を越える見つけるために一歩一歩をフォローしたい、プロセス指向技術、製品です。
当社の技術は、問題が何であるかをプロセス一度、見ているバックの問題は非常に時間がかかることがあり、製品を作ることです。
各チームは、彼らのプラットフォームを使用するために、製品の専門家が、計画の専門家、開発の専門家、運用・保守の専門家、彼らはその機能を公開するAPIを使用する方法、およびを持っていることをクロスファンクショナルチームにマイクロサービスアーキテクチャシステム、チームの組織のニーズを使用機能リリース製品。
マイクロアーキテクチャ技術サービスシステム
私は、ほとんどの企業で使用されますマイクロテクノロジー・サービス・システム・アーキテクチャを共有しましょう：
サービス検出
三種類に分け主流のサービス発見、：
まず、将来におけるプログラムの開発者は、私たちが対応するサービスを見つけることができます言葉を通じてドメイン名を持つ運用・保守、DNSサービスがあります。
欠点は、サービスが、負荷分散サービスの負荷分散されていないため、大幅なパフォーマンスの問題があるかもしれない、ということです。
第二に、それが一般的です。Zuulゲートウェイは、組み込みのレジストリに登録されている機能、サービスサーバを介して、各サービスを参照することができ、消費者が投票に引き続き、組み込みのロードバランシングコールサービスを使用し、サービスレジストリを対応発見しました。
欠点は、多言語環境は良くありません、あなたは、負荷分散の消費者のクライアントサービスの発見と開発を分離する必要があります。もちろん、この方法は通常、春クラウドで使用されています。
第三は、むしろ、同じプロセス内よりも、同じホスト上のクライアントとロードバランシングです。
この方法は、比較的に第一、第二の方法、それらの欠点を改良したものであるが、非常に操作および保守のコストを増加させるであろう。
ゲートウェイ
マイクロゲートウェイサービスとは何ですか？私たちは考える現実の生活に連絡することができます。すべての大企業は、ビルドアップされたエリア、警備員がたくさんあり、自分の一方的な建築面積を、持っています。そこに外国人労働者は会社にあり、かつガードが最初に取得するには、挨拶を築くだろう。場合
ゲートウェイの意味を理解することは困難ではないマイクロサービスにリンクされている現実の生活、：
いいえ公共の純粋な笑顔の記事ません：[12]私はマイクロサービスアーキテクチャを描く手に従ってください！
マイクロサービスとは何ですか？
微服务架构是一种架构模式或者说是一种架构风格，它提倡将单一应用程序划分成一组小的服务，每个服务运行独立的自己的进程中，服务之间互相协调、互相配合，为用户提供最终价值。
服务之间采用轻量级的通信机制互相沟通（通常是基于 HTTP 的 RESTful API ) 。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。
另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建，可以有一个非常轻量级的集中式管理来协调这些服务。可以使用不同的语言来编写服务，也可以使用不同的数据存储。
根据马丁.福勒的描述，我总结了以下几点：
①小服务
小服务，没有特定的标准或者规范，但他在总体规范上一定是小的。
②进程独立
每一组服务都是独立运行的，可能我这个服务运行在 Tomcat 容器，而另一个服务运行在 Jetty 上。可以通过进程方式，不断的横向扩展整个服务。
③通信
过去的协议都是很重的，就像 ESB，就像 SOAP，轻通信，这意味着相比过去更智能更轻量的服务相互调用，就所谓 smart endpoints and dumb pipes。
这些 Endpoint 都是解耦的，完成一个业务通信调用串起这些 Micro Service 就像是 Linux 系统中通过管道串起一系列命令业务。
过去的业务，我们通常会考虑各种各样的依赖关系，考虑系统耦合带来的问题。微服务，可以让开发者更专注于业务的逻辑开发。
④部署
不止业务要独立，部署也要独立。不过这也意味着，传统的开发流程会出现一定程度的改变，开发的适合也要有一定的运维职责。
⑤管理
传统的企业级 SOA 服务往往很大，不易于管理，耦合性高，团队开发成本比较大。
微服务，可以让团队各思其政的选择技术实现，不同的 Service 可以根据各自的需要选择不同的技术栈来实现其业务逻辑。
微服务的利与弊
为什么用微服务呢？因为好玩？不是的。下面是我从网络上找到说的比较全的优点：
-
优点是每个服务足够内聚，足够小，代码容易理解这样能聚焦一个指定的业务功能或业务需求。
-
开发简单、开发效率提高，一个服务可能就是专一的只干一件事。
-
微服务能够被小团队单独开发，这个小团队是 2 到 5 人的开发人员组成。
-
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
-
微服务能使用不同的语言开发。
-
易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如 Jenkins，Hudson，bamboo。
-
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。微服务允许你利用融合最新技术。
-
微服务只是业务逻辑的代码，不会和 HTML，CSS 或其他界面组件混合。
-
每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库。
总的来说，微服务的优势，就是在于，面对大的系统，可以有效的减少复杂程度，使服务架构的逻辑更清晰明了。
但是这样也会带来很多问题，就譬如分布式环境下的数据一致性，测试的复杂性，运维的复杂性。
微服务带了种种优点，种种弊端，那么什么组织适合使用微服务？
①墨菲定律（设计系统）和康威定律（系统划分）
康威定律，是一个五十多年前就被提出来的微服务概念。在康威的这篇文章中，最有名的一句话就是：
Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.
中文直译大概的意思就是：设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。
看看下面的图片，再想想 Apple 的产品、微软的产品设计，就能形象生动的理解这句话。
②架构演化
架构是不断演化出来的，微服务也是这样，当从各大科技公司，规模大到一定程度，完全需要演化成更进一步管理的技术架构体系。
传统的团队，都是面向过程化的，产品想完了去找策划，策划完了找开发，接着顺着一步一步找。
我们做技术都是为了产品的，一旦过程出来了什么问题，回溯寻找问题会非常耗时。
使用了微服务架构体系，团队组织方式需要转变成跨职能团队，即每个团队都有产品专家，策划专家，开发专家，运维专家，他们使用 API 方式发布他们的功能，而平台使用他们的功能发布产品。
微服务技术架构体系
下面我分享一下大部分公司都使用的微服务技术架构体系：
服务发现
主流的服务发现，分为三种：
第一种，开发人员开发了程序以后，会找运维配一个域名，服务的话通过 DNS 就能找到我们对应的服务。
缺点是，由于服务没有负载均衡功能，对负载均衡服务，可能会有相当大的性能问题。
第二种，是目前普遍的做法。可以参考 Zuul 网关，每一个服务都通过服务端内置的功能注册到注册中心，服务消费者不断轮询注册中心发现对应的服务，使用内置负载均衡调用服务。
缺点是，对多语言环境不是很好，你需要单独给消费者的客户端开发服务发现和负载均衡功能。当然了，这个方法通常都是用在 Spring Cloud 上的。
第三种，是将客户端和负载均衡放在同一个主机，而不是同一个进程内。
这种方法相对第一种第二种方法来说，改善了他们的缺点，但是会极大增加运维成本。
网关
微服务的网关是什么？我们可以联系生活实际想一下。每一个大的公司，都会有一偏属于自己的建筑区，而这建筑区内，都有不少的门卫。如果有外来人员进入公司，会先和门卫打好招呼，才能进去。
将生活实际联系到微服务上，就不难理解网关的意思了：