ウェブサイトを学習による高同時高可用性、O2O、マイクロサービスアーキテクチャ https://www.itkc8.coメートル
ありがとうございましたhttp://www.cnblogs.com/skyblog/p/5044486.html
アーキテクチャについては、私はそれがより良い、より複雑ではないと考えているが、逆に、最後の言葉は、今ここに言及することは、あまりにも簡単です。それは、市場を見てみると、サービスアーキテクチャをそこに持っても、原因に人気のマイクロサービスです：EJB、SCA、ダボ、など、マイクロより高度なサービス、完璧よりもミクロサービス、それらのどれもがそうマイクロサービスに引っ掛かっていません、彼らはあまりにも複雑なため。シンプルは、ハイテク、アップルの携帯電話は、ユーザーがより簡単な操作作る方法を研究する特別チームを持っていると言われています。大企業は、同社が少しの時間と労力は、フレームワークを選択しないだろうと感じた場合には、小さな会社によって開発され、技術選択のプロセスの開始時に大企業に中小企業の発展、一般的にプロセスシステムの継続的な最適化を伴っていますしばらく絶えず最適化技術とフレームワークを開発することを選択しない傾向にあるが、元の基盤の改善、そしておそらくそれは、人気のシンプルなフレームワークの本質です。
当社が事業保険代理店事業の超高容量のために、「インターネット+」保険プラットフォームを設計する必要があるとします。2000万登録ユーザー、店舗、フランチャイズの売上高20,0002億1年間の保証の量のこの保険オンライン保険代理店事業規模を想定すると（中国Pingの総加入者は167万人に達し以上798000生命保険の販売スタッフに関する付き246 000フルタイムの従業員は2015年6月30日の時点で、当社グループの総資産は、株主資本に帰属は3,311.90億円、4630000000000元に達した。現在では、インターネットのリーダー中安保険保険は、主にマイクロファイナンスで動作しますアリババに裏打ちされているので、毎日億保険契約までの売上高が、他）は、それが困難中安保険モードをコピーするために見つけます。私たちは、この保険の保険O2Oプラットフォームを検討するために、大きなインターネット企業や公共の安全のトレードオフを取るようにします。
lは分析が必要です
次のコア需要行列を取得するために参考保険事業関連の文書（不完全なドキュメント）、（それはあまりにも多くの機能が含まれているため、単に大きなファンクションポイントを取ります）。
| 分類 |
機能 |
品質 |
制約 |
| Eコマース（B2C） |
製品（検索、表示、およびその他の詳細） |
タイムリーな応答、セキュリティ、堅牢性、使いやすさ |
保険の様々な種類、治療が異なる場合があります |
|
|
購入（注文、支払いを提出） |
タイムリーな応答、セキュリティ、堅牢性、使いやすさ |
保険の様々な種類、治療が異なる場合があります |
|
|
ユーザーセンター（私の政策、私の主張など） |
タイムリーな応答、セキュリティ、堅牢性、使いやすさ |
保険の様々な種類、治療が異なる場合があります |
| マネジメントエージェント（フランチャイジー管理） |
保険自動車保険（お問い合わせ、記録シングル、支払い） |
タイムリーな応答、堅牢性、拡張性 |
保険の様々な種類、治療が異なる場合があります |
|
|
非保険の自動車保険（お問い合わせ、記録シングル、支払い） |
タイムリーな応答、堅牢性、拡張性 |
保険の様々な種類、治療が異なる場合があります |
|
|
クエリポリシー |
タイムリーな応答、堅牢性、拡張性 |
|
|
|
ドキュメント管理 |
タイムリーな応答、堅牢性、拡張性 |
|
|
|
マイアカウント（私の政策、コミッション決済） |
タイムリーな応答性、安全性、信頼性、使いやすさ |
保険の様々な種類、治療が異なる場合があります |
| ドケット管理 |
ドケットエントリ |
タイムリーな応答、堅牢性、拡張性 |
保険の様々な種類、治療が異なる場合があります |
|
|
収集請求データ |
タイムリーな応答、堅牢性、拡張性 |
|
|
|
転送ファイル |
タイムリーな応答、堅牢性、拡張性 |
|
|
|
ファイルの追跡 |
タイムリーな応答、堅牢性、拡張性 |
|
| 顧客管理 |
顧客情報のメンテナンス |
タイムリーな応答、堅牢性、拡張性 |
大きなファイルをアップロードします |
|
|
顧客活動管理 |
タイムリーな応答、堅牢性、拡張性 |
|
|
|
案件管理 |
タイムリーな応答、堅牢性、拡張性 |
|
|
|
私のプラットフォーム（ニュース、イベント、ビジネスチャンス） |
タイムリーな応答、堅牢性、拡張性 |
|
| 保険アジャスター |
追跡ヘルプの損傷過程を評価するための自動車保険 |
タイムリーな応答、堅牢性、拡張性 |
保険の様々な種類、治療が異なる場合があります |
|
|
負傷者を支援するChuxian |
タイムリーな応答、堅牢性、拡張性 |
保険の様々な種類、治療が異なる場合があります |
|
|
法律扶助サービス |
タイムリーな応答、堅牢性、拡張性 |
保険の様々な種類、治療が異なる場合があります |
観点から、O2Oのコンセプト：「O2Oすなわち、オンライン、オフライン、また、ビジネスのラインとの機会についてインターネットオンラインショーマンシップの消費にサービスをオフラインで使用できるように組み合わさは、インターネットにラインのフロントオフィスの取引を行います。サービスのすべての種類は、されていない促進効果見つけることができ、各トランザクションは、「（Baiduの百科事典）に追跡することができます。オンラインサービスを使用してスクリーニング、およびオンライン取引の決済、すぐにモデルの規模に達する最も重要な機能があるさすることができますO2Oのため。商品の販売は、あなたが店で買うことができるので、適したO2Oていないお店から直接整列する必要はありません。しかし、保険サービスの下で、それはサービスのために満たす顧客の需要にできなくなり、純粋なラインがある場合は、オンライン、オフラインを組み合わせて、する必要がありません。O2O線サービスは、フランチャイズ加盟店、薬することができ、また、コンセントかもしれません。
単語「システム」が、ここではシステムの使用がなどのソフトウェアシステムや人事、システムを含むことができる抽象的な概念があるが、上記の要件は、ユーザの視点に基づいて作られています。.. 上記の要件は1つが、エンドユーザのオンラインサービスのために純粋である、3つのカテゴリに分けることができます：電子商取引サイト（B2C）; 1は、エージェントサービスのために特別である：エージェントシステム、残りはいくつかの公共サービスであり、いくつかのサービスに使用されるシステムのEコマースサイトやエージェントに可能です。また、最大の問題の保険事業は、保険の種類を扱う、より保険ですなリンクスなど通常の大型電子商取引サイトとの差で、すべての商品は、主に次のシングル、同じサービス（同じですが、非常に異なっていますこれは、B2Cのも、ウェブサイト異なる単一の操作、短い保険、生命保険、自動車保険、などでオンラインでも保険商品）これを表明することにある、と、保険サービス、複数の異なるこれらのサービスの多くがあります言うまでもありません。一般的にはこれに対処で伝統的な保険会社は、そのようなので、上の生命保険制度、保険制度と同様に、複数のシステムを行います。
Lシステム分析
我々は前述のインストールの事業規模解析（仮定）より重要な性能要件のいくつか：
A）製品：保険商品ではない、現在の行に続けます
b）のB2Cサイトの毎日の訪問：5000万PV
C）B2Cの製品購入同時ピーク：2000 TPS
オンライン同時にd）の運転・維持管理体制：10000（20000総販売員またはエージェント）
同時ピークのe）の運転・維持管理体制：2000 TPS
f）はショート保険順序：年間シングル1.85億
g）のロング保険順序：年間5億
H）自動車保険のご注文：年間千万
ⅰ）情報ファイル：百万新しい単年度
毎日の訪問5000万や製品を同時2000我々が想定するが、TPSは、受注データの変更と前の変更との仮定、顧客情報やファイルの情報である総生産2億受注毎年、しかし、保険の種類に応じて、短いリスク（旅行保険、障害保険）は、特別な処理を必要と受注の大幅な90％を生産しました。それは特別な処理を必要とするので、自動車保険、及び長期リスク（主に生命保険など）に加えて、被保険者またはサービスかどうか、かなり異なっています。
私たちは、上記の要件に従うので、最初の大きな責任によるシステム分析は、サービスと同じ義務を分割されます。である「品質」の機能を、追加する必要があり、この性能要件とし、すべての機能要件の上に、「高い同時実行」の高い同時実行は、すべてのデザインに影響を与えます。また、あなたがあるため保険とは異なるアプローチの種類のよりスケーラビリティ、セキュリティ、最も重要なのは、保険の行のためのインターネットプラットフォームの品質特性シーケンスをしたい、とあれば、加えて、高い同時実行性と信頼性は、直接の機能に影響を与えます達成、しかし、大規模な拡張性に影響を与えませんでした。次のようにキーテクノロジーの詳細な分析は、各機能の責任の後に記載されている達成するために：
| クラスの需要 |
実装要件 |
達成するためのサブシステムとサービス |
ハードウェアとソフトウェア技術 |
| クライアント |
B2C電子商取引サイト |
B2CのWebクライアント |
クラスタの展開、キャッシング、分散キャッシュ、検索エンジン技術、静的 |
| B2C電子商取引サイト、モバイルクライアント |
B2Cアプリケーションクライアント |
|
|
| エージェント管理 |
Webプロキシクライアント |
クラスタの展開、キャッシング、分散キャッシュ、検索エンジン技術、静的 |
|
| モバイルクライアントを管理するためのエージェント |
弁護士のクライアントアプリケーション |
|
|
| プロセス管理ファイル |
ウェブクライアントファイルの処理 |
クラスタの展開、分散キャッシュ |
|
| 顧客関係管理 |
顧客管理Webクライアント |
クラスタの展開、分散キャッシュ |
|
| 保険鑑定の管理 |
保険アジャスターWebクライアント |
クラスタの展開、分散キャッシュ |
|
| 製品管理の運用・保守 |
Web Clientのプロダクトマネジメント |
クラスタの展開、分散キャッシュ |
|
| 文と金融統計 |
財務諸表と統計Webクライアント |
クラスタの展開、分散キャッシュ |
|
| パブリックサービス |
操作と製品管理、Webアクセスのフロントエンド製品のメンテナンス |
製品とサービス |
クラスタの展開、分散キャッシュ |
| Eコマースの注文管理やエージェント |
オーダサービス |
クラスタの展開、分散キャッシュ |
|
| このような電子商取引や金融業務に関わる薬として |
元帳サービス |
クラスタの展開、分散キャッシュ |
|
| 文と金融統計 |
サービスを報告 |
クラスタの展開、分散キャッシュ |
|
| 業務サービス |
B2C电子商务网站及手机客户端个人账户 |
B2C个人账户服务 |
集群部署、分布式缓存 |
| 代理人管理 |
代理人管理服务 |
集群部署、分布式缓存 |
|
| 案卷处理管理 |
案卷处理管理服务 |
集群部署、分布式缓存 |
|
| 客户管理 |
客户管理服务 |
集群部署、分布式缓存 |
|
| 保险公估管理 |
保险公估管理服务 |
集群部署、分布式缓存 |
|
| 短险开放式接入 |
开放式接入平台服务 |
集群部署、分布式缓存 |
|
| 工具性服务 |
保险公司产品对接 |
产品对接服务 |
集群部署、消息队列 |
| 在线支付 |
第三方支付服务 |
集群部署 |
|
| 短信邮件通知 |
通知服务 |
集群部署、消息队列 |
|
| 性能监控 |
日志采集服务 |
集群部署、消息队列 |
|
| 文件服务器 |
文件服务 |
集群部署、消息队列 |
|
| 服务授权与审计 |
服务授权与审计服务 |
集群部署 |
|
| 分布式事务管理 |
分布式事务管理服务 |
集群部署 |
|
| 定时任务管理 |
定时任务服务 |
集群部署 |
各个子系统及模块的关系如下图。
其中订单服务、产品服务、财务服务、工具服务为基础服务，其它各个业务模块的服务会调用这些基础服务。各个业务模块的服务都是根据业务领域进行划分的，同一业务领域下实现技术不同会被划分为两个服务，比如产品展示和订单原本属于同一个大的领域，但其因为实现技术和质量要求不同需要划分为两个服务。因为短险接入量大，而且大部分是跟第三方合作接入，因此设计短险接入公共接口服务平台处理大量短险订单。
l 存储及缓存架构
对于大型的高并发系统来讲，最重要的当属数据的架构。我们在前面也提到过，web系统业务处理模块本身就可以集群部署，当用户出现高并发时最先遇到的瓶颈就是数据库访问的瓶颈。这也是我们说数据架构最为重要的原因。其实web系统是典型的“计算机信息系统”，也就是说一切以数据（信息）为基础，所有的功能都是围绕着数据来的。这也是我们在这里说数据是web系统最重要的，很多公司在做少用户量web系统时直接设计好数据库就可以开发了。
按照上面划分的业务领域我们设计多个数据库，技术选项包括“是否读写分离”、“是否水平切分”及“路由键”。其中路由键是指在进行水平切分后，我们使用那个“标识”去查询数据库，一般来说会使用该业务领域聚合根对象的主键作为路由键。
| 数据库 |
是否读写分离 |
是否水平切分 |
水平切分路由键 |
| 产品数据库 |
是 |
|
|
| 订单数据库 |
|
是 |
客户ID |
| 公共数据库（元数据、公共数据） |
是 |
|
|
| 客户管理数据库 |
|
是 |
客户ID |
| 案卷管理数据库 |
|
是 |
客户ID |
| 代理人服务数据库 |
|
是 |
代理人ID |
| B2C电子商务个人账户数据库 |
|
是 |
客户ID |
| 保险公估数据库 |
|
是 |
客户ID |
| 工具数据库（短信、支付、文件） |
|
是 |
客户ID |
| 报表数据库 |
是 |
|
|
| 日志采集服务数据库 |
|
是 |
日志ID |
除工具数据库外，其它的数据库的划分很容易理解。工具数据库的数据也大都跟客户或说用户有关，比如“产品对接服务”，产品对接服务是指用户在购买了保单后，系统会自动对接到具体的保险公司接口去上传保单信息和下载保单，所以水平切分数据库时可以采用用户ID作为路由键。“在线支付”和“通知服务”也是类似，都是保存用户相关的数据，在线支付服务保存的是用户在线支付的流水，通知服务保存的是发送给某用户的短信或邮件。
另外在数据架构中我们也可以看到一个规律，就是使用了水平分库的存储结构就不能再使用读写分离，原因是防止存储单元过度泛滥，因为使用了水平分库之后，本身也要为数据库建立多个备份库，这个时候如果再用读写分离需要建立一套只读库，数据库的数量将增加一倍。使用了分库后我们可以把热点数据存储在分布式缓存中以起到读写分离类似的作用。
另外缓存也是存储技术的一种，而且非常重要。从日常生活中我们也可以看到这一点。比如你要去购买一台电脑，你会发现二级缓存和内存大的价格高出很多，如果你的显卡显存巨大，那将是顶级配置，发烧级配置。手机也是一样，内存大的手机速度明显快，价格也高，如果内存和持久化存储都高，那也是顶级配置。对于web系统也是一样，有些大型web系统只要缓存处理的好，数据库不需要分库就可以承载亿级的用户，比如维基百科、新浪微博等。也因此，不管是电子商务网站还是互联网+大型应用，都会在它们的架构中看到缓存大量使用的情况。
从整个web系统的架构来看，缓存在两个层面大量使用，分别是展示层和逻辑层，展示层通常使用高速的页面缓存，逻辑层通常使用高并发的分布式缓存。当然有些分布式缓存工具既可以在逻辑层使用也可以在显示层使用。
| 系统 |
是否使用CDN |
是否使用高速缓存服务器（varnish） |
是否使用分布式缓存（redis） |
| B2C电子商务网站 |
是 |
是 |
|
| 报表及财务统计Web端 |
|
是 |
|
| B2C个人账户服务 |
|
|
是 |
| 代理人管理服务 |
|
|
是 |
| 案卷处理管理服务 |
|
|
是 |
| 客户管理服务 |
|
|
是 |
| 保险公估管理服务 |
|
|
是 |
| B2C个人账户服务 |
|
|
是 |
| 短险公共平台服务 |
|
|
是 |
l 逻辑架构
在给出系统总体的逻辑架构前，我们先看看系统前端和服务层直接的关系。前端是客户端，可以有多个客户端，也可以有多种客户端，比如手机端（APP、WAP、微信）等。客户端和服务之间的架构是典型的MVC架构，V是客户端，C就是spring mvc或servlet开发的控制层，对于Web应用V和C在开发角度是一个工程，剩下的M就是服务层。这是对于web系统来说的，对于app或者使用html直接实现的客户端，或者是.net实现的桌面客户端，由于这些客户端是单独开发的，没有控制层，因此需要增加一层“API 网关”作为这些客户端的控制层。
图中的服务组件就是指各个业务服务，这些服务可以看成是组件的概念。通常前端界面一个界面中需要的数据通常不仅仅来自于同一个服务，即使是来自于同一个服务，那也来自于很多不同的接口，servlet或api 网关作为控制层，所起到的作用就是组合接口、组合数据，并处理接口间的事务性。另外服务组件也是分层的，图中并没有展现，一般可以分为3层，从低到高依次是工具性服务组件、基础业务层服务组件、业务层服务组件。前端界面的请求按照从高到底向下传递和处理请求。
按照职责、通用性、技术特性综合考虑和计量，逻辑架构设计如下图：
十几个子系统分别分布在服务层、控制层、表现层（典型的三层架构）。实体层和接口访问层虽然属于“层”，但它们并不单独发布，而是使用Jar包类库的方式提供给其它服务调用，是逻辑上的层。服务组件的构成大都是按照业务领域划分的，只有一个除外，就是“B2C网站”，B2C网站由于是面向终端用户的高并发电子商务网站，为了处理高并发，我们将其拆分为两个业务领域（也可以拆分成多个业务领域，看实际并发量），分别是用户账户和产品。用户浏览产品并购买，这是电子商务网站最基本的两个领域。其中产品浏览等功能由更底层的产品服务提供，用户账户功能由会员服务提供。还有一些功能，比如推荐商品可能是由其它服务提供，这些可以在控制层直接组合这些服务。
l 服务架构
服务框架采用典型的“服务注册表”模式，注册表使用redis。服务组件在启动时将自己注册进服务注册表，web服务器或api 网关在访问服务时查询服务注册表得到服务的uri，然后调用某服务接口。
淘宝的dubbo使用的是zookeeper作为服务注册表，之所以使用zookeeper，主要是使用它的负载均衡的功能。笔者认为restful接口没有必要使用zookeeper做负载均衡，可以使用nginx（负载均衡服务器都可以），所以没必要选用动态的zookeeper作为注册表，而是使用“redis+心跳监测”机制（redis也可以换为LDAP等）来完成服务注册和监控失效服务的功能。这个方案至少比dubbo简单几个数量级，简单就是硬道理。
在注册服务时只需要注册nginx服务器的IP以及服务描述信息即可。反观dubbo还要注册接口进注册表，笔者认为这个没必要，因为调用一个服务接口的充分必要条件就是知道服务器的IP即可。至于调用什么服务接口，肯定在代码里已经写死，目标服务器必定存在这个服务接口。将服务接口注册进服务注册表如果是为了监控审计服务的使用情况，那这个功能使用访问日志来实现能做的更好。
总体的分布式拓补结构如下图：
对于服务集群来讲，看上去像是一个大哥（nginx）带有众多小弟的结构。访问某服务群组只需要访问其nginx服务器即可，这里nginx均采用高可用方案，防止单台nginx出现问题。至于高层服务调用底层服务也是直接访问其服务器组的nginx。这个执行的流程其实和日常生活中的概念很像，如公司内部的执行流也是如此：老板分配任务给部门经理，部门经理分配任务给主管，主管分配任务给具体的个人（某单台服务器）。领导们起到的作用也是负载均衡和监控，负载均衡就是把任务可以分配给多个人同时执行（并且某个执行失败自动切换），监控就不必说了就是监控任务完成情况。在我们的方案里，会专门有个服务去监控所有服务器的执行情况，很简单的服务就可以做到。
l 关于分布式事务
如果研究一下EJB就会发现，EJB和微服务的架构基本相同，甚至所有面向服务（SCA、SOA等等）的架构都相差不大。很多人反对EJB，并不是EJB不够强大，而是它不够简单，它给项目带来的复杂性甚至超过了项目本身（这也是笔者不建议使用dubbo框架的原因）。曾有人说过：你要么把事情做的尽可能简单，让人挑不出毛病；要么把事情做的尽可能复杂，让人找不出毛病，EJB就是后者。EJB分布式事务机制实现的很好，可惜的是这种“一刀切”的事务机制，大大降低了web系统的性能，所以几乎所有面向互联网的应用都极少使用分布式事务，也就不会采用EJB。互联网应用本身事务性操作并不多，一些新闻、博客之类的网站甚至都不需要事务。另外一个方面，即使出现一个或两个分布式事务应用场景，也可以通过其它手段解决，比如事件机制等等。
在之前的文章中我们也提到过对于分布式事务最佳的策略是尽量避免。如果避免不了将按以下方式实现。
1） 将分布式事务性操作封装在一个服务中，这个服务使用XA或链式分布式事务管理。
2） 可以使用事件机制协调事务管理（具体做法就是事务失败后发失败事件到可持久化的消息队列，然后需回滚操作的接口监控此事件并执行回滚）。
3） 使用自定义分布式事务管理器管理分布式事务。
笔者设想的自定义分布式事务管理器主要是封装了流程及分布式事务相关功能，笔者将在其它文章专门讨论。如图所示，假设有一个事务需要依次调用ABCDE五个接口，我们首先调用分布式事务管理接口创建这条“流程”的实例，实例中五个接口分别对应五个状态，调用成功后将该接口对应的状态设置为“成功”，反之就是“失败”，流程处理结束后，分布式事务检查状态，然后按照一定的策略调用失败接口的反向操作接口去回滚数据（前提条件也是参与分布式事务操作的接口要开发反向操作接口）。这既是一个简单的流程引擎，也是一个分布式事务协调处理装置，具体是否有必要做的复杂（比如处理并行流程），还要看实际环境下分布式事务的情况，但笔者认为互联网前端应用使用简单流程应该足以应付。
l 开发架构
系统所需的工程，“[ ]”里面表示工程的名称。
从图中不难看出，我们将运维相关前端界面合并为一个前端系统，总体来讲前端只有3种，B2C前端、APP前端、运维前端。把运维前端合并为一个项目有利于加快前期的开发、部署的效率，在后期如果某子系统功能界面太多，可以将前端系统独立，比如公估系统、客户管理系统等，独立后的系统需要使用单点登录，这样就可以在各个系统之间免登陆切换。
开发环境：
编码：UTF-8
工具：Myeclipse 10
SVN：Site-1.8.22
Web服务器：Tomcat7
JDK: JDK1.7、 Java EE 5
开发环境：Maven 3
高并发高可、O2O、微服务架构用学习网站 https://www.itkc8.com
开发技术选型：
表现层：Bootstrap+Html+Jquery
MVC框架：Spring MVC 3.2
安全框架：Spring security 3.2
Rest接口实现：Spring boot
持久层：Mybatis3.2
分布式缓存：Redis
数据库：MySql 5.6