Javaの新鮮なビジネスプラットフォーム - マイクロサービスアーキテクチャの概要

Javaの新鮮なビジネスプラットフォーム - マイクロサービスアーキテクチャの概要

 

モノマー現在の建築の問題

伝統的なソフトウェア技術アーキテクチャのシステムでは、基本的には、単一のアプリケーションまたは単一プロセス内のビジネス機能に焦点を当てます。が、ソフトウェアアーキテクチャと設計原理の近代的な理論は、長年にわたって延長されてきたが、実際の技術は変化とモチベーションの欠如のゆっくりとしたペースを導出しました。複雑さと多様性の存在理由は、私が主な理由は断固としてシステム再構成を実装し、顔に安定性のリスクを下げるために、エンジニアを可能に総合的なソリューションではないと思います。アプリケーション・システムは、ビジネスの急速な発展に特に敏感な時間スケール、より顕著になるシステムの重要性である場合には、開発者は、システムを改革以前から放浪躊躇し、過去の技術的な解決策の唯一の継続より保守的になってきています、我々は、元のシステムアーキテクチャに機能を蓄積していきます。このようなシステムは、ピラミッド豆腐、スタックのリスクが高いようです。素晴らしいサービスの圧力に直面したときしたがって、システムはとの契約をサポートするために、方法によって拡大にあります。ことわざは、「小さなボートUターン」になるように、「頭の病気の治癒ヘッド、足の病気ではなく、病気。」肥大化したシステムでは、実際に体全体に影響を与えてしまう具体的な展開を行いません。特定のパフォーマンスのボトルネックを備えたサービスの動作の違いのため、主観評価結果と不確実性があるように、サービスは、孤立して存在せず、そのような拡張の作用の下で、この相互作用が異常になったので、難しい、拡大は、その結果、定量化することができない「バケツ効果。」

効率の開発と実施を改善し、問題へのよりエレガントなまたは適切なソリューション可能にするためにアプリケーションシナリオのサイズを増加すると、開発者が評価し、より高度な技術を選択し、進化を推進していきます。過度なアプリケーションシステムに必要なサービスを行うことができ、すべての機能を集中管理し、そしてあなたが新しい技術を適応させる必要があるときに依存するライブラリは、巨大になっている原因で、不確実性だけでなく、競合に対処するのは難しいと困難に依存しているので、作るありリファクタリングは、新しい技術を適応することの難しさを増す、非常に困難になります。

機能が1に設定されているので、アプリケーションのリソース使用量がますます大規模になってきているように、継続的インテグレーション、回帰テストを行うこと、および展開は、配布することがますます困難になります。例えば、ディスクの会計アプリケーションの展開パッケージが増加し、それをコンパイルして、パッケージ、配布、長い起動時間、不確実性が大きくなります。アプリケーションがオンラインに公開すると、機能的欠陥の存在は、試行錯誤と時間コストがより高価になるので、ロールバックする必要があります。

より多くの機能は、システム・アーキテクチャ、開発プロジェクト、および実行環境への依存度を集中します。この実行環境は、データ、サービス、および設定、開発プロセスを中断し、問題とデバッグ環境を診断し続けることを余儀なくされた問題の一部は、迅速な開発を行うことはないローカルはもちろんのこと、アクセスできなくなるために必要がありますを運びます開発。システムの安定性はより不確実になるように、過度の依存、環境上のが原因。第1に、サービスの相互依存関係、および開発者のため、彼らは環境に依存したサービスへと減らす、あるいはそれ以上の統合テストに依存するテストの一部を作り、ユニットテストの依存習慣を減らします。第二に、とき展開の成功率を減らすために継続し、実行時間が増加して、開発時間を圧縮し、それが遅れにつながる可能性があるだけでなく、テスト環境で統合テストを実行するために人員の展開をテストします。システミック・リスクを増加させ、そして心理的負担を増やすだけではなく。そう言って、迅速な開発とテストの両方がより困難になってきました。

上記の分析はまた、単にビジネスとテクノロジー、急速な事業の発展、その成長率と拡大よりも効率的な開発に精通している人のメンバーにとどまる、新採用と開発は不可欠なツールです。このような巨大な、複雑なシステムアプリケーション、ビジネス、特に雑種になるために必要な技術的な知識に直面したとき、夫婦は「さまようロードを行い、一人で見てタワー」感覚を持っていた、学習曲線が急勾配です。実際の実装プロセスでは、文書の完全性と体系的な指導が不十分です。

モノマーアーキテクチャ既存の問題を解決する方法

リアリティモノマーアプリケーションは、私たちをもたらしました。

• 拡張難しい（スケーラビリティの問題点）
• 展開の難しさ（展開の問題点）
• 投稿ロールバック困難（リリースロールバックの問題点）
• 新技術を適応の難しさ（新技術の採用の問題点）
• 迅速な開発の難しさ（RADの問題点）
• テストの難易度（テストの問題点）
• 学習困難（学習の問題点）

実際に、単一のアプリケーションの問題に対処するには、数年前には、そのようなSOA技術的なルートとして対応するソリューション、ありました。

SOAは、実際の問題を解決するために、それはサービスとネットワークプロトコルを介してサービス間の呼び出しに変換サービス、古いプロセスにおけるサービスコール、間のデカップリングです。初期のCORBA、RMI、COMの+、XML-PPC技術だけでなく、原因特定のテクノロジーやプラットフォームなどRMI、マイクロソフトの技術システムのCOM +一環として、Javaプラットフォーム技術の一部にこれらの技術の結合に、表示される問題を発明したことから、XML = PRCは統一の標準プロトコルではありませんので、強く、プラットフォームに依存しないプロトコルの音声通信ニーズのために、その後、典型的な技術のいくつかは、このようなWebサービスやメッセージキューとして、現れ始めます。同様に彼らのマスターの技術的なESBなど。

これは持っている技術を表し：WSDL（Webサービス記述言語）、SOAP（シンプルオブジェクトアクセスPrototol）技術。なぜならこれらの比較的嵩高い通信プロトコル規格の、まだ広く使用されているが、段階的に廃止されるであろう傾向です。

なぜSOAおよび選択されたマイクロサービスを選択していません

サービス指向アーキテクチャ（SOA）VSマイクロサービス

同様の

• サービス（サービス指向）について
• 疎結合（疎結合）
• 自己完結型（自己完結型）
• プラットフォームの独立性（プラットフォームに依存しません）

違い

• 原子性（アトミック）
• 自治（自律）
• 運用・保守システムの開発（DevOpsチーム）
• 軽量（軽量）
• 通信プロトコル（通信プロトコル）

マイクロSOAサービスの粒度は、より良い原子性を達成することは不可能である、からこそ巨大なSOAシステムの、小型で、かつ方法は、それは、このような大規模なソリューションESBとして統一されたルールを、使用しています。このような技術の選択は、自己管理を実現することができない単一のサービスのために、チームは目に見えない運用・保守コストを増大させます。開発者はよくDevOpsチームの技術を実装されていません。同時に、WSDL、SOAPや他のヘビー級の通信プロトコルを使用したSOAは、開発コストとパフォーマンスの損失を増加させました。マイクロサービスでは、大幅な適応のコストを削減暴露の道、によって、ほとんどのサービスのREST API。

トレンドマイクロのサービス

のは、Googleと百度統計、それの結果を見てみましょう

 

写真.PNG

春ブーツで図（1）Google検索の関心

春ブーツと春の雲は最高のマイクロサービスパートナーを行うことです。チャート（1）から、我々は2017年2月まで、100を加熱するために、世界で以降人気の春ブーツ2013を見ることができます。

 

写真.PNG

春の雲の中図（2）Google検索の関心

グラフ（2）から、我々は2012年に始まり、春の雲を見ることができるマイクロサービスが上昇し始めたとき、比較的穏やかな熱は、2015年6月後、つまり、春の雲は、2017年2月には、急速に成長し始めています検索熱が100に達しました。（中国では、中国が理由のうち壁であると思われるので、地図上ではありません）

 

 

図（3）春ブーツBaiduの検索は、熱を検索します

（3）図は、Baiduのマップ統計の結果であり、我々は国の春ブーツは、2015年6月にあった2017年に人気となった見ることができ、成長が特に顕著です。

 

 

図（4）検索春の雲Baiduの検索関心

私たちが見ることができる（4）図、2016年6月からの春の雲は、それが、今では中国で、一年前に見て、シリコンバレー、シリコンバレーの後ろの年になります、中国で人気が、中国では多くの場合、新技術普及するようになりました我々は、2018年2月に中国の暑さの中で春の雲が頂上に到達する、つまり、中国の発展曲線の春の雲を決定することができるであろう。

人気が意味するものではありませんが、あなたが必要です。彼の人気に人気の理由があるので、しかし、彼は利点がありました。その後、我々は次のマイクロは、サービスを認識し戻ってくるだろう。

マイクロサービスとは何ですか

マイクロサービスは、サービス、およびサービスの間（例えば、RESTfulなインターフェースなど）の軽量通信メカニズムを介して相互作用、サービスが異なるプロセスで独立して実行し、小規模なサービス・アプリケーションを構築する方法のセットで自動展開によって独立して展開することができます。異なるサービスを開発するために別の言語を使用するか、ビジネスニーズに基づいて、データベースの異なる種類を使用するように、そのためのマイクロサービスアーキテクチャの間で、サービスは、互いに独立しています。

マイクロ・サービス・アーキテクチャの利点と課題

優位

• 服务简单，只关注一个业务功能
  传统的整体风格的架构在构建部署和扩展伸缩方面有很大的局限性，其服务端应用就像是一块铁板，笨重且不可拆分，系统中任何程序的改变都需要整个应用重新构建和部署新版本。在进行水平扩展时也只能整个系统扩展，而不能针对某一个功能模块进行扩展。 而微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立且松耦合，单一功能的改变只需要重新构建部署相应的服务即可。

• 每个微服务可由不同团队开发
  传统的开发模式在分工时往往以技术为单位，比如UI团队、服务端团队和数据库团队，这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工，不同的服务可以采用不同的技术来实现，一个团队中应该包含开发所需的所有技能，比如用户体验、数据库、项目管理。

• 微服务是松散耦合的
  微服务架构抛弃了ESB复杂的业务规则编排、消息路由等功能，微服务架构中服务是高内聚的，每个服务都会处理相应的业务，所有的业务逻辑应该尽量在服务内部处理，且服务间的通信尽可能的轻量化，比如使用Restful的方式。

• 可用不同的编程语言与工具开发
  传统的软件开发中经常会使用同一个技术平台来解决所有的问题，而经验表明使用合适的工具做合适的事情会让开发变得事半功倍。微服务架构天生就具有这样的特性，我们可以使用Node.js来开发一个简单的报表页面，使用C++来编写一个实时聊天组件。

挑战

• 运维开销
  更多的服务也就意味着更多的运维，产品团队需要保证所有的相关服务都有完善的监控等基础设施，传统的架构开发者只需要保证一个应用正常运行，而现在却需要保证几十甚至上百道工序高效运转，这是一个艰巨的任务。

• DevOps要求
  使用微服务架构后，开发团队需要保证一个Tomcat集群可用，保证一个数据库可用，这就意味着团队需要高品质的DevOps和自动化技术。而现在，这样的全栈式人才很少。

• 隐式接口
  服务和服务之间通过接口来“联系”，当某一个服务更改接口格式时，可能涉及到此接口的所有服务都需要做调整。

• 重复劳动
  在很多服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不同的服务团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的很多原则。

• 分布式系统的复杂性
  微服务通过REST API或消息来将不同的服务联系起来，这在之前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者需要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等，而面对如此多的微服务都需要分布式时，整个产品需要有一整套完整的机制来保证各个服务可以正常运转。

• 事务、异步、测试面临挑战
  跨进程之间的事务、大量的异步处理、多个微服务之间的整体测试都需要有一整套的解决方案，而现在看起来，这些技术并没有成熟。

微服务设计原则

• 隔离
  服务必须设计为单独相互隔离工作。当你将一个整体单片系统分解成一组服务时，这些服务必须彼此解耦，这样才能更加连贯和自给自足。每个服务应该能够处理其自己的故障，而不会影响或破坏整个应用程序或系统。隔离和解耦特性使服务能够非常快速地从故障状态中恢复。服务的隔离特性具有以下优点：容易采用连续交付，更好的扩展，有效的监控和可测试性。

• 自治性
  隔离为自治性铺平了道路。 服务必须设计为自主自治的。它必须具有凝聚力，能够独立地实现其职能。每个服务可以使用良好定义的API（URI）独立调用。API以某种方式标识服务功能。自主服务还必须处理自己的数据。更流行的术语是多语言持久性，其中每个服务都有自己的持久存储。 自主还确保弹性。自主服务具有以下优点：有效的服务编排和协调，更好的扩展，通过良好定义的API进行通信，更快速和可控的部署。

• 单一责任
  服务必须设计为高度凝聚。单一的职责（责任）原则是服务只执行一个重要的功能。 单一责任与“微观”一词很好地结合。‘微’意味着小，细粒度，只与其责任范围内相关。单一责任功能具有以下优点：服务组合无缝，更好的扩展，可重用性，可扩展性和可维护性。

• 有界上下文
  您的服务应该有多大或小？ 答案就在于所谓有界上下文设计原则。这是一个关键模式，同时是领域驱动设计（DDD）建模方法。有界的上下文是关于微服务将提供其服务功能的上下文。它根据有关领域模型和识别离散边界，并相应地设计您的微服务，使其更具凝聚力和自主性。这也意味着跨边界的通信变得更有效率，在一个有界上下文中的服务不需要依赖于另外一个有限上下文中的太多的事情了。

• 异步通信
  在设计离散边界和使用其自己的有界上下文设计服务时，跨边界的服务通信必须是异步的。异步通信模式自然导致服务之间的松耦合，并允许更好的缩放。使用同步通信，会阻止调用并等待响应。 处于阻塞状态的服务不能执行另一个任务，直到接收到响应并释放底层线程为止。它导致网络拥塞，并影响延迟和吞吐量。异步通信还可以带来实现良好定义的集成或通信模式的概念，以实现涉及不同服务的逻辑工作流。

• 位置独立
  根据设计，微服务是在虚拟化环境或docker容器中部署。随着云计算的出现，我们可以拥有大量可以利用动态缩放环境的服务实例。服务可以在跨小型或大型集群的多个节点上运行。服务本身可以根据底层计算资源的可用性或效率来重新定位。必须能够以位置独立的方式来寻址或定位服务。通常，可以使用不同的查找发现模式来消费使用您的服务。服务的客户端或消费者不必烦恼部署或配置特定服务的位置。它只是使用某种逻辑或虚拟地址来定位服务。