詳細なSOAベース高い並行性と高可用性分散システムアーキテクチャおよびコンポーネント

分散型の高可用性アーキテクチャとマイクロアーキテクチャのサービスをSOAベースの、インターネットは、今日の繁栄の企業システム開発のアーキテクチャのオプションです。コア思考、提案両側セグメント及びシステムの拡張では、システムは、高可用性サービスとクラウドサービス系エラストマービルド間の通信のための特定の手段を用いて、異なるサービス機能モジュールに応じて分割されます分散ソリューション。

しかし、それらの間の違いは、特にクラウドサービスと組み合わせたサービスと深さの使用に反映され、類似点より以上であってもよいです。実際には、マイクロアーキテクチャのサービスもはるかに大きな規模SOA分散システムを形成するために一緒に他のインターネットミドルウェアと組み合わせることができます。本論文では、詳細な説明を行うための分散アプリケーションの典型的なSOAのアーキテクチャとコンポーネントに焦点を当てています。

エンタープライズシステムアーキテクチャの進化

一枚岩

MVCデザインパターンに基づいて、すべてのシステム機能およびモジュールの、すなわちモノマーアーキテクチャは、単一のサーバ装置に接続されています。伝統的なMVCの考え方に基づいて、モデルによって前後端の分離の原則に基づいて、モノリシックアプリケーションは、コントロールとビューは、サービス要求を完了するために一緒に仕事を提供しています。マルチプレイヤーモードのチームワーク、コードの更新やメンテナンスを持つこの伝統的な建築、展開の継続的な困難は、もっと重要なのは、このアーキテクチャは、高い同時実行のためのインターネット業界の需要をサポートすることはできません。以下の図はモノマーモールアーキテクチャとSSMの実装アーキテクチャの典型的なアプリケーションを示しています。

 

モノリシックアプリケーションの詳細についてはで見つけることができます:

サーブレットコンテナの詳細なサーブレットJavaWebと開発

SSMのJavaのWebアプリケーション開発の原則に基づき、

クラスタ

少なくとも高並行性の要件では、欠陥モノマーのアプリケーションは、業界ではそれが並行処理性能を向上させる方法を、耐え難いのですか?アイデアはクラスタに、マルチボディになるために、直接、単一のアプリケーションで、サービスを分散することで、異なるアプリケーションサーバーの負荷分散に要求。また、これは初期の淘宝網のソリューションです。ここでは、クラスタ・アーキテクチャのスケッチは、次のとおりです。

クラスタのアーキテクチャは、効果的に高い同時実行の問題を解決するが、保守および可用性の問題をもたらすことは非常に困難ですが。また、関数には、それはユーザーのシングルサインオンを解決するものであっても、セッション放送、資源のブロードバンドと消費の方法によってする必要があります。生まれ高い同時実行のためのクラスタが、しかし、あなたはノード数でさえ強い増加、十同時レベルの何千ものに到達したい場合は、パフォーマンスが大幅に改善されません、ボトルネックがあります。

分散

複数のサーバーにプロジェクトコードの展開と同等のクラスター、上に、独立して展開され、各サーバが実行し、そして、複数のサブシステム間の通信の必要性をシステムモジュールに合わせていくつかのサブシステムに分割され、という考えを分散共同ビジネス・プロセスを完了します。以下に示すようなアーキテクチャを分散。 

分散型アーキテクチャは、多くの利点があります。

  1. 分割されたモジュール、モジュール間の結合を低減するために、インタフェースを使用して通信を行います。
  2. いくつかのサブプロジェクト、別のサブプロジェクトを担当する別のチームにプロジェクトを分割するには。
  3. ただ、することができ、他のシステム・インタフェースを呼び出し、サブプロジェクトの増加機能を追加する必要があります。
  4. 分散配置の柔軟性。

しかし、対応する現像圧力をもたらす分散通信インターフェースの開発は、学習チームのコストを増加させます。 

SOAベースのアーキテクチャ

SOA:サービス指向アーキテクチャサービス指向アーキテクチャの。これは、プロジェクトがエンジニアリングサービス層、プレゼンテーション層のプロジェクトに分割されています。サービス層は、ビジネスロジックが含まれている、あなただけのサービスを提供する必要があります。インタラクション、ビジネスロジックとプレゼンテーション層のみを達成するために、すべてのページのコールサービス層を処理する必要があります。プロジェクトが独立して展開することができます。 

典型的なSOAアーキテクチャでは、サービス間の通信を含む分散アーキテクチャに由来する問題を解決するための通信及びサービスのためのミドルウェアおよびサブシステムの多くを追加して、ロード・バランシング、リバースプロキシ、情報センター、文書管理、バックアップからマスター、など。

詳細なコアモジュールとミドルウェア

生まれ高い同時実行のためのSOAアーキテクチャは、異なるサービス間の並行性の高い通信の問題の下に対処する必要があります。実際には、SOAのアーキテクチャは、その上のキャッシングサービス、データベース、ミドルウェア、パブリッシュおよびサブスクライブ・サービス、メッセージキュー、などのミドルウェア技術の様々な必要があります。以下は、一般的なモールSOAアーキテクチャ図です。

まず、システム間通信

一般的な、SOAベースのアーキテクチャでは、そのプレゼンテーション層とサービス層は、異なるプロジェクトです。だから、サービスプロセスを実現するためには、2つのシステム間で通信する必要があります。それでは、どのようにリモート通信?一般的な方法は次のとおりです。
1、Webサービス使用して高効率、(HTTP + XML)SOAPプロトコルに基づいています。プロジェクトが推奨されていません。
2、サービスのRESTfulな形式ます:http + JSON。アプリケーションの多くのプロジェクトを。サービスは、より多くの、サービスおよびサービスの複雑な、洗練されたコール管理サービスのURLとの間の関係を呼び出した場合、マシンを追加する際に決定することは困難です。
3、使用Dubbo。使用rpc协议进行远程调用,直接使用socket通信。传输效率高,并且可以统计出系统之间的调用关系、调用次数,管理服务。
Dubbo
DUBBO是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,是阿里巴巴SOA服务化治理方案的核心框架,每天为2,000+个服务提供3,000,000,000+次访问量支持,并被广泛应用于阿里巴巴集团的各成员站点。Dubbo组件的架构和工作机制如下图所示:

Zookeeper

注册中心负责服务地址的注册与查找,相当于目录服务,服务提供者和消费者只在启动时与注册中心交互,注册中心不转发请求,压力较小。使用dubbo-2.3.3以上版本,建议使用zookeeper作为注册中心。
Zookeeper是Apacahe Hadoop的子项目,是一个树型的目录服务,支持变更推送,适合作为Dubbo服务的注册中心,工业强度较高(稳定性好),可用于生产环境,并推荐使用。

二、分布式文件服务器

在分布式应用中,无法通过传统手段解决文件上传和下载问题。因此,对于文件上传,业务系统节点可以把文件集中到分布式文件服务器做统一管理,而用户访问,也可以通过分布式文件服务器提供快速的文件下载支持。

FastDFS

FastDFS是用c语言编写的一款开源的分布式文件系统。FastDFS为互联网量身定制,充分考虑了冗余备份(高可用)、负载均衡(高并发量)、线性扩容(添加服务器或者磁盘)等机制,并注重高可用、高性能等指标,使用FastDFS很容易搭建一套高性能的文件服务器集群提供文件上传、下载等服务。
FastDFS架构包括 Tracker server和Storage server。客户端请求Tracker server进行文件上传、下载,通过Tracker server调度最终由Storage server完成文件上传和下载。
  • Tracker server作用是负载均衡和调度,通过Tracker server在文件上传时可以根据一些策略找到Storage server提供文件上传服务。可以将tracker称为追踪服务器或调度服务器。
  • Storage server作用是文件存储,客户端上传的文件最终存储在Storage服务器上,Storage server没有实现自己的文件系统而是利用操作系统 的文件系统来管理文件。可以将storage称为存储服务器。

FastDFS架构和工作机制如下图所示:

三、负载均衡

以一个SOA商城系统为例,它的首页是系统的门户,也就是系统的入口。所以首页的访问量是这个系统最大的。如果每次展示首页都从数据库中查询首页的内容信息,那么势必会对数据库造成很大的压力,所以需要使用缓存来减轻数据库压力。实现缓存的工具有很多,现在比较流行的是Redis。
Redis是用C语言开发的一个开源的高性能键值对(key-value)数据库(nosql),应用在缓存、任务队列等场景较多。

四、搜索功能

Solr

SolrCloud(solr 云)是Solr提供的分布式搜索方案,当你需要大规模,容错,分布式索引和检索能力时使用 SolrCloud。当索引量很大,搜索请求并发很高,这时需要使用SolrCloud来满足这些需求。
SolrCloud是基于Solr和Zookeeper的分布式搜索方案,它的主要思想是使用Zookeeper作为集群的配置信息中心。Solr集群架构图如下:
Zookeeper它有几个特色功能:
  • 集中式的配置信息(数据库连接池的配置文件,修改文件不用重启就可以生效)
  • 自动容错
  • 近实时搜索
  • 查询时自动负载均衡

五、消息队列

MQ

MQ是一个消息中间件,比如:ActiveMQ、RabbitMQ、kafka都属于MQ,是MQ的产品。一般可以考虑使用Apache开源的消息队列ActiveMQ。

ActiveMQ的消息形式 

对于消息的传递有两种类型:
  1. 一种是点对点的,即一个生产者和一个消费者一一对应;
  2. 另一种是发布/订阅模式,即一个生产者产生消息并进行发送后,可以由多个消费者进行接收。
JMS定义了五种不同的消息正文格式,以及调用的消息类型,允许你发送并接收以一些不同形式的数据,提供现有消息格式的一些级别的兼容性。
六、反向代理
Nginx
Nginx是一款高性能的http 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器。由俄罗斯的程序设计师Igor Sysoev用c语言所开发,官方测试nginx能够支支撑5万并发链接,并且cpu、内存等资源消耗却非常低,运行非常稳定,而且开源。Nginx的应用场景包括:
  1. http服务器。Nginx是一个http服务可以独立提供http服务。可以做网页静态服务器。
  2. 虚拟主机。可以实现在一台服务器虚拟出多个网站。例如个人网站使用的虚拟主机。
  3. 反向代理,负载均衡。当网站的访问量达到一定程度后,单台服务器不能满足用户的请求时,需要用多台服务器集群可以使用nginx做反向代理。并且多台服务器可以平均分担负载,不会因为某台服务器负载高宕机而某台服务器闲置的情况。
七、主从备份
Keepalived
keepalived是以VRRP协议为实现基础的,VRRP全称Virtual Router Redundancy Protocol,即虚拟路由冗余协议。
虚拟路由冗余协议,可以认为是实现路由器高可用的协议,即将N台提供相同功能的路由器组成一个路由器组,这个组里面有一个master和多个backup,master上面有一个对外提供服务的vip(VIP = Virtual IP Address,虚拟IP地址,该路由器所在局域网内其他机器的默认路由为该vip),master会发组播,当backup收不到VRRP包时就认为master宕掉了,这时就需要根据VRRP的优先级来选举一个backup当master。这样的话就可以保证路由器的高可用了。
keepalived主要有三个模块,分别是core、check和VRRP。core模块为keepalived的核心,负责主进程的启动、维护以及全局配置文件的加载和解析。check负责健康检查,包括常见的各种检查方式。VRRP模块是来实现VRRP协议的。

おすすめ

転載: www.cnblogs.com/aibabel/p/11665968.html