この記事では、アリババ技術協会（ATA）から来ているコレクション。淘宝網の電力供給システムは、10年前に業界のベンチマーク、TOP1、強大なプラットフォームを行うには、商品のシステムが矢面に立つです。歴史から学ぶためにこのような経験は十分。
1.背景ステータス
詳細現在の問題は、「Detail2.0紹介」（2014年7月）で見つけることができ、この記事では詳細には触れません。目標は、他の詳細に横方向に再利用、また、非ディテールのシナリオで使用することができ、新しいプラットフォームの詳細の共同効率/安定性/拡張性を向上させるビジネスリスティングに正規化を促進することです。製品の研究・開発がコーミングと復興、モジュラー、SDK / APIと定義し、協力メカニズムを展開し、合成を提供する他の方法を取って、ビジネス革新の急速に変化するニーズに対応するために2つの展開モデルをグループ化しているの寸法を拡大します。そして、統一されたパッケージ管理ツールやプラグ注入の安定性とパフォーマンス、なるように正規化と標準化。
2.定義
モジュールとは何ですか
モジュールは、標準化されたソフトウェアを追跡するために、展開、管理、再利用可能な、組み合わせ、および他のステートレス特性を備えており、外部インターフェース部を提供しています。
プラットフォームとは何ですか
プラットフォームは、再利用可能な保守性、拡張性の高い、コラボレーティブおよび他の特性を備えた完全なシステム・テクノロジーとアーキテクチャ、で、研究開発段階の作業を調整し、最終的には、種の多様性、個性やその他のビジネス目標をサポートすることができます。
モジュールプラットフォーム
プラットフォーム・モジュールの特性で見つけることができる特性が同じである追求。プラットフォームは、マクロアーキテクチャ上にある間にマイクロモジュールは、ユニットの具体的な実現です。モジュラーは不可欠な要素とプラットフォームを構築する方法であるので、2つは競合しません。システムモジュールの変換を現在の問題を解決するため、そして、モジュールライブラリを編成する、スケジュール、及び最終的なプラットフォームを実現するために、様々な他の寸法の外側に加えて、研究開発能力を強化するためにモジュラーコンセプト。
3.デザインコンセプト
（現在のシーンのために、非繰り返しの普遍的な原則のみ）
分割統治
それは、複雑な問題を解決するための効果的な方法であるモジュラー具体的な実装です。特にビルド（マルチチームコラボレーション）とシーンを変化するニーズの下で、より多くの再利用可能な、メンテナンス性、制御の複雑さをモジュール、およびので、簡単に理解すること。そして、今日のJavaプラットフォームは、ジグソーパズルやOSGiのは、すべてのまだ進化しているかどうか（詳細は詳細には触れていない）が、モジュラーコンセプトとモデルがいる限り、システムが適切に設計され、あるとして、汎用的であるにかかわらず、モジュラーアプローチしているスプリット、あなたは利益を得ることができます。そのため、独立した設計軽量モジュールの仕様では、このプラットフォームのためのエントリポイントです。
ガバナンス体制
これは、順番に経口ような方法を文書または弱い仕様、それは無秩序な行為を蓄積されますされている技術仕様を開発することが判明深く埋め込まれたアーキテクチャになりました。そう規格によって定義されたフレームワーク、R＆Dプロセスを尊重し、標準化を達成します。しかし、フレームの制約に加えて、仕様に応じて、だけでなく、同じ仕様の下でオープンできます。単に治水などの無秩序な行動のためのガバナンス、および完全にスパースブロックされていません。したがって、モジュール枠仕様は、フレームワークの具体的な症状である仕様の非常に軽い薄いベース部分であるが、フレームワークは、よりオープンなサポートと拡張することであるだろう。
モジュールのサイズ
本実施識別モジュールでは、モジュールは、モジュール管理モジュール枠によって受け入れられる独立した論理パッケージサイズ、症状、代わりに、それは再利用することが可能です。私は実際には、モジュール仕様に準拠の外部露出部分を気にし、内部ロジック、階層的なコードなどを気にしないでください。
ポジショニングプラットフォーム
決してベースプラットフォームの同じタイプ別のリストのような相対的なIC / TC / UIC、それは淘宝網は、「論理的な再パッケージによるアーキテクチャの基礎となる、直接、独自のデータに属していないが、バックエンドサービス上に配置されていないので（注） 「と」各サービスの振り付け、「トップ・ビジネスシステムの実装。よりエレガントな長期的な視点からは、唯一のバックエンドサービスを前提とする論理である必要があり、「アレンジャー」ポスト、あなたは、特定のビジネス・ロジックの実装を持つことができません。
注：商品の詳細ビジネス・ロジックを提供するバックエンド・サービス・インターフェースに主に依存するが、他の歴史的な理由の低いバックエンドインタフェースパッケージ、依然として約10％未満がある（各バックエンドインターフェースの比によっては異なる）論理「残留」ディテールに。内部の詳細・システムは、ビジネスロジック層、データアクセス層などが、淘宝網の大きなビューアーキテクチャ分析を分離することができますが、詳細は、プレゼンテーション層のための唯一のさまざまなビジネスシステムとインフラストラクチャプラットフォームのです。
4.プラットフォーム
4.1。分離前端と後端
なぜなら歴史問題の詳細は、フロントエンドビジネスロジック層で散乱の多数を含むJSコードとVMテンプレートを含むあります。その開発効率が低下するので、デュープロセスと依存性ファジー境界を共同作業する際表裏側、ロー、制御ロジックの後端部が弱くなり再利用、複雑で面倒なメンテナンスのフロントエンドは、そのようなレイヤ。これらの問題を解決するには、まずすべてのリストプラットフォーム事業の分離（またはデカップリング）の終了前と後に行われます。
バックエンドビジネスロジック、プレゼンテーション、インタラクティブフロントエンドロジック（まとめて論理を経験）：ビューシステムのためのロジックを分割することができます。ユーザーの行動に応じて、プレゼンテーションロジックのテンプレートのレンダリング、対話ロジックを担当するビジネスロジック出力データサービス、。フロントおよびセパレータの後端は、デカップルビジネスロジックと経験に、ビジネスロジックを完全にフロントエンド層へのプレゼンテーションの再利用性および発現を増強するためのバックエンドをシンクによって制御されている職務との相互作用の役割を果たしています。
フロント及び論理デカップル後端部が、前端と後端と失わない相互作用のみを分離し、サービス・データ・インターフェースの後端が連通管の前端と後端となります。それでは、私たちは、プラットフォームのインターフェースを含む規範的な定義、あるプロジェクト：モデルの定義（パラメータやモデルの結果など）、セキュリティ（認証および認証など）、コール・プロトコル（HTTP / RPC）形式に、復帰（JSON / JSONPなど）、およびJavaのサポートとは、地元のネイティブモードをお勧めします。
商品の詳細は、前と終了後に、フィールド内のバックエンドのビジネスルールや機能がより整体になりますが、また、フロントエンドのユーザーエクスペリエンスに焦点を当てて、前後端がちょうど標準化、独自の並列ロジックの実装を開始するには、共同作業をするときに従う後に分離しました以下に示すように、責任明確な境界は、ヘルプには、効率を向上させます。
また、フロントの分離とミッドウェイの後端を懸念してください
4.2モジュール変換
モジュールプラットフォームプロジェクトの設計仕様やモジュールレベルのアプリケーションのためのサービスを解体するアプリケーション（モノリシック）の全体アーキテクチャの実装フレームワーク。ソースクラスによって軽量モジュールのフレームがあり、その後のライフサイクル管理クラス/入力/出力/通話モード/安定性を含む、一元管理を実現するためにパッケージ化。実際には、ソースクラスがまだ実行できるように、フレームが破棄されます、モジュールフレームに依存しない、論理設計クラスと階層モードに侵入していない気にしないでください。
の中核を構成します
-
AbstractModuleは、各モジュールが競合を回避するために、別のクラスローダにロードされ、すべてのモジュールの基本クラスであります
-
あなたはLifecycleListenerことにより、モジュールのライフサイクルを監視することができます
-
拡張ポイントは、入口宣言アノテーション（@Annotation）に拡張可能です
-
拡張子は、基本クラスの実装を拡張したものです
コードの実装
-
基本的な定義モジュール
パブリック最終クラスExampleModuleが延びるAbstractModule / *実装LifecycleListener * / {
@オーバーライド
保護ExampleResultはModuleExceptionを{スロー（RunDataデータ、ModuleContextコンテキスト）を実行します
// ...
}
}
-
最小記述モジュール
必要なモジュールとして＃Module.properties同じ層
モジュールが必要= XxxModule @ 1.0.1、YyyModule、ZzzModule
#orモジュール - ローカル= XxxModule @ 1.0.1、YyyModule、ZzzModule
モジュールの説明=何も
ライフサイクル定義
ライフサイクルリスナー（オプション）
パブリックインターフェースLifecycleListenerは、イベントリスナーを{延び
公共のボイド変更（イベントイベント）;
}
モジュールコンテナ
あるメインモジュールコンテナフレームは、ローカルインタフェースモジュールを介して公開されたサービス指向のインタフェースとして公開、プロトコルをリモーティングの富を提供し、パッケージのインタフェースのセキュリティサービスされていた、サービス後のバッチ処理や他の機能のためのサポート、いいえ、モジュラーコンテナモジュールは、ローカル通話をサポートしていません。外部モジュールコンテナ管理モジュールのサポートサービスの範囲に加えて、フックを提供するが、管理モジュールのこの部分は、まだ実現されません。
サポートツール
管理、およびIDEプラグインやモジュールのライフサイクルとバージョンの開発段階のために他のツール。まだ開発インチ
プラグインシステム
ロギングツール（例えばSLF4J）、ツール（例えば、スイッチ）の安定性を、較正パラメータ、および他の一般的に使用されるオーケストレーションモジュールライブラリは、フレームへのプラグインモジュールの形で、各モジュールは、開発コストを削減するために、開発の一貫性を維持するために使用することができますそして、保守性を向上させます。均一に狙いをプラグインするようになって定義されたインタフェースライブラリではモジュール内のコードを変更せず、交換またはライブラリをアップグレードする場合は必要性を保護することです。今、フレームのログスイッチプラグが完了しました。
（近期针对模块化进行部份改造优化，后续会针对模块规范和框架实现再单独详细介绍）
4.3.代码重构
详情项目基于上述模块规范，再对业务逻辑重新梳理、对原有代码彻底重构，并按共建型、模块化、可扩展的设计思路重新分层。在新的层次中，每一层内的每一点在逻辑实现后，凡向上暴露接口时均以模块方式表达，上层通过模块描述发现下层能力。整个平台运行在模块容器上，模块容器运行在应用服务器之上。
4.4.稳定性
淘宝商品详情前辈们在多年稳定性实践中积累了丰富的经验，并沉淀了包括静态化/异步化/单元化等全局架构，平台化项目在继续受益延用的同时也在代码层做了统一性和标准性的优化，目标稳定性治理常态化。
-
模块的安装卸载，保障模块级稳定性，使得最少有一层保护
-
模块被手工或自动卸载后，可降级其它许可版本或触发容灾
-
模块内有否实现容灾会在模块安装前被校验，使之成为必然
-
在批量执行模块时（常见场景），模块框架可并发执行并为每个模块设定不同的超时时长以提升性能
-
因各层通过模块框架组织，而模块框架支持稳定性框架以插件的形式嵌入，使得各模块能统一使用
-
新的平台分层里，上层调用二方服务必需通过Adapter层（此层不开放共建，主要是将外部服务进行符合模块规范的适配并未有多余的逻辑）。在适配层进行对外部服务的统一稳定性治理，包括开关降级/容灾/超时控制等。使之前但凡要调用外部服务就直接使用就造成需多次稳定性治理的情况得以改善，降低维护成本。Adpater层内各模块或其它各层的模块，也能针对来源设定不同的限流阀值
4.5.测试体系
Detail受历史原因也碍于代码的分层结构和代码的不规范性，未能实现行之有效的测试方案，所以测试工作回归量大、重复劳动、枯燥无味、效率低下。而平台化项目针对现状重新整理了Detail的技术质量体系。
分层测试
根据代码分层，技术质量维度也进行了对等的分层单元测试。各层主要包括：基础服务层(如DAO/Util等)、业务逻辑层(如Service/Manager等)、对外接口层(此层进行接口级测试)、页面展现层等。而Detail场景大都是依赖更后端的服务化接口，所以在Detail新平台的单元测试中为提升效率引入了PowerMock框架。
自动方式
除页面展现层外，其它各层均实施自动化测试方式，而页面展现层更多的还是需要通过手工介入方式来进行功能测试。能够代替手工测试、找出重复测试工作是进行自动化方式的思路。而在衡量自动化测试目标时，也应从追求自动化覆盖率，到追求正确率、关注运行时间、测试脚本可重用性等，进行全方位的提升。
持续集成
基于分层单元测试、自动化测试，才能实现最终的持续集成。持续集成平台通过跟踪代码库的变更而自动执行测试用例、静态扫描等，这样便能快速发现问题，当然也要在环境部署之前触发，同时持续集成平台还应支持执行对应的用例，比如，只修改了AbcUtil.java那么则只执行AbcUtilTest.java。将持续集成定义为常态化，设进标准流程，融入日常工作，不断有所追求，最终高效保障淘宝商品详情平台的技术质量。
4.6.研发模式
没有规矩，不成方圆。商品详情平台作为一个设计完整的平台，还针对各维度定义出一套规范(或称标准)、针对各阶段设计出一套流程，以指导平台化后的研发模式。包括：模块开发规范、提测标准、质量标准(包括业务逻辑质量标准、性能标准、稳定性标准、安全标准、可维护标准也包括运维)、发布流程(含紧急发布流程)、线上问题处理规范，这些规范和流程面向参与平台建设的所有前后端开发、测试、运维等各角色。
规范是必需要建立起来的指导原则，在通过商品详情平台化的实践后，针对规范的落地也更有理由相信：
1、设计再良好的架构，也是需要依靠合适的组织结构去保障的；
2、架构的认同、执行、维护，最终需转变团队成员的思想，这是一个过程；
3、尽量将规范和流程用以工具、示例等更形象更直接方式表达。
另一方面，在共享共建大背景下，平台在搭建之初也针对共建进行设计，无论是共建理念定位、模块逻辑结构、物理部署方式，再到各维度能力的协同。以下便是经过模块化改造后商品详情平台的共建研发模式：
商品详情新平台提供两种协作模式：
1、 独立模块级共建
默认共建方式。各方基于Aone二方库进行共建，一个二方库即一个模块，二方Jar包即模块单元，二方库内代码实现需符合模块规范才可被识别和部署。该方式在研发过程和部署方式上更灵活，更可管理，共建方的可控性更强，但对于Detail主维护团队所提供的平台底层扩展能力(即SDK)要求较高。
2、 源码分支级共建
多人基于同一个源码工程，通过开多个分支的方式，在各分支上实现业务逻辑，最终各个分支在整体合并后进行部署。优势是允许从底层能力至上层业务更大范围内进行编码，更具连贯和顺畅性，但缺点是分支和流程冲突大难以协调、业务理解能力和编码实现习惯各有不同，容易逐渐造成架构被腐蚀。
商品详情新平台更加关注“共建方体验”，在新架构和新研发模式的基础上，共建方将得到如下体验和权力：
4.7.部署结构
平台逻辑架构和部署物理结构，因所面临的问题领域和解决方式各不相同，所以不能互相限制对方的最终形态，即不能因为平台逻辑架构而绑死最后部署结构，这是平台化项目的架构设计基本原则之一。更何况在业务高速发展，需求多变，团队协作的特定场景，更是要求部署模式也一样的灵活，按需定制，可组合。
5. Use Cases
成功案例
农业Detail全部承载
挑食Detail全部承载
虾米Detail全部承载，暂未上线
旅行Detail部份后端接口
等等……
其它业务场景
高速业务场景：针对大型的垂直业务或快速发展的业务，在除主站Detail集群即主平台外，只需采购所需的业务模块（也可远程调用），就可以在独立集群再进行部署，业务方只需关注自身模块的开发迭代，其余的模块包括基础框架均由Detail团队负责推送更新，便可自行掌控所有权限和节奏，还能共享同一套CDN静态化体系。如当业务成熟、需求逐渐减少，认为有必要时，只需向Detail团队提供模块即可回归主平台。
无线终端场景：某APP或HTML 5端需要部份接口，Detail直接提供远程服务或将所需要的模块接入MTOP
非详情的场景：某页面需展现SKU，可将Detail前后端的SKU模块拿走，从后端数据到前端渲染及SKU选择计算就统统包括；某页面非商品详情但需展现卖家档案可结构略不同，则复用卖家档案模块，前端部份自行实现。复用时可直接拿走卖家档案模块包自行部署提，也可找Detail团队先沟通后直接调远程服务
等等……
=>更多文章请参考：《中国互联网业务研发体系架构指南》
https://blog.csdn.net/Ture010Love/article/details/104381157
=>更多行业权威架构案例、领域标准及技术趋势请关注微信公众号 '软件真理与光'：
