星期五, 08月 15th, 2008
构建架构的思考
（说明：以下内容仅仅是一种思考，而不是某家公司的具体内容，在此过程中，参考了多篇 DBA Notes上关于一些公司互联网架构的介绍，在此表示感谢！同时参考了其它一些关于架构介绍的文章。很欣赏我同事[程立]的一句话，用中国古典文化阐释架构的源和重要性 — 老子说”道生一、一生二、二生三、三生万物”。在业务愿景的技术实现过程中，假设”道”为愿景、一为方向、二为战略的话，三就应该是架构了，架构既出，万物化生可矣。”）
1. 第一要素
关于什么是架构，已经有很多文章在讨论了，本文不予以探讨。
关于架构的类型，业界的定义也各不相同，《架构的类型》对这个问题进行了探讨，可供参考。
此处所探讨的架构可能包含了企业架构、系统架构、软件架构、信息架构、SOA架构等方面的部分要素，所适用的行业，也仅限于互联网行业。在此，引出了构建良好架构的第一个基本原则：依据业务特征选择架构。例如，Amazon、EBay、FaceBook、YouTube等互联网企业的架构都非常的不同，每家公司都有自己独特的架构特征，首要因素就在于第一要素。
2、第二要素：哲学原则
之所以称之为哲学原则，首先它们比较虚，就像黑洞那么虚；其次度量起来比较困难，没有一个统一的标准，也很难定义标准，例如不同机构对客户满意的定义就不一样；再次它们的确很通用，在架构的各个阶段、各个层面、各种粒度都适用。
它包含如下子元素：
- 使客户(所有直接或间接使用这个系统的人都是客户)满意 – 功能、质量、使用、体验
- 良好的投资回报率 — 复用、免费产品、成型产品
- 足够敏捷，适应业务的发展，且能够快速推出新业务 – 可发展性
- 支撑企业核心竞争力
- 简单又实用
- 强壮又稳定 （ 架构设计必须考虑到故障—业务故障的可恢复性、技术故障的可恢复性，非常状态的故障：电力不足、机房断网、自然灾害等，冗余和错误恢复也是达到稳定的必要手段）
- 术语一致性（有点像统一思想、统一口径）
- 可维护性
- 支持未来的发展
- 对运营友好 （尽可能自动化，是对运营不错的支持）
3、第三要素：量变引起质变 （驱动架构进化的因素）
“量变是指事物单 纯数量上的增加或减少，事物保持其质的稳定性。质变是指事物根本性质的变化，在这阶段，事物处于剧烈的变化之中，其平衡静止被打破，旧的事物转化为新事 物。事物的变化总是先从量变开始的，待量变积累到一定程度后，才会发生质变，其中量变是质变的必然前提，质变是量变的必然结果，量变→质变→新的量变是事 物发展的基本规律”。这条哲学规律同样适用与系统架构，每次大的系统架构的变化，背后的动因都是”量”引起的【类似window这样的系统架构变化的动因，不在此处的探讨】。在互联网领域，如下主体的量起到很大的作用：
基本量：
- 用户 — 总量/日访问量/并发量/增长率
- 访问量（PV） — 日访问量/并发量/响应周期
- 产品 — 数量/业务领域量
被动量：
- 业务数据 — 历史总量/日变化量/并发量/增长率
- 系统日志 — 一段区间总量/日生成量
- 业务日志 — 历史总量/日变化量/并发量
- 事务量 — 日变化量/并发量/响应周期
- 外部网络 — 流量/并发量
- 内部网络 —并发量
- 网络连接 —并发量
- 图片 —总量/日访问量/并发量/增长率
- 项目【包括日常升级、日常BUG维护】 — 平均开发周期/项目组成员增长率/测试周期/发布时间
- BUG — 确定原因周期/响应周期
- 系统服务（SOA角度的服务） — 总量
- 设备 — 总量
- 内部抱怨 — 声贝的大小
- 停机维护 — 次数/时间
基本量是基础，它驱动被动量的变化，例如用户，日访问量会引起业务数据、网络连接等的变化，基本量的变化对架构的影响最大，时刻关注基本量的升降。
【注意：】不用业务领域，重点关注的主体略有差别
4、本文探讨的架构包含的元素
上面是针对互联网产品的一种架构【产品架构和业务架构是都需要针对自身的特点进行划分，不具有通用性】。
- 产品架构的目的
能够描绘当前产品的关系、分类；
能够体现公司的核心价值、核心竞争力；
能够实现公司的战略意图；
能够支撑现有产品的管理和标准化进程、以及未来产品的规划；
能够指导产品的可持续发展、创新；
为技术架构提供产品输入。
- 业务架构的目的
能够描绘当前业务的关系；
能够支撑公司的战略；
能够支撑产品在既定方向上发展；
能够支撑业务的发展和敏捷；
为技术架构提供业务输入。
- 技术架构的目的
能够描述当前的IT状况；
能够支撑对产品的发展；
能够为客户提供高质量的服务【非功能性方面的需求】。
为技术架构选择的几个子架构域：
-
信息域
此处的信息特指用户交互层面的信息、跨系统的信息、内部管理的信息。本域内关注用户信息展示、信息聚合、信息共享、信息交换、信息分析和挖掘等。
-
基础技术域
支撑IT的基础设施，该域包含硬件基础、系统基础、应用基础环境、通用技术（例如：工作流、ESB、搜索等）、程序驻留环境（类似FaceBook的开放平台）等。
-
数据域
支撑数据的存储（数据库存储、文件存储【例如：BigTable】、甚至存储在S3中）、访问（透明统一的访问）、分布（物理分布、水平切分数据、垂直切分数据）、缓存、备份、归档等。
-
部署域
支撑系统（此处单指一个独立的物理整体，例如运行在一个JVM上的所有的内容）和服务（单指SOA服务）的运行、管理、发布、分布（同城、异地）、日志等。
-
治理域
为公司业务的运营提供不同粒度的（硬件、系统粒度、产品粒度、服务粒度、客户粒度等）监控、报警、控制、隔离，以及服务的版本管理等。
-
安全域
为公司业务的安全提供硬件、软件、业务等方面的支撑。
-
测试域
为产品提供测试环境、生产环境、沙箱环境、性能环境等的支撑。
-
分析域
支撑公司运营、管理、客户分析、智能系统等（从简单的URL分析、到服务路径的分析、定向客户分析等）。
架构的三要素（产品、业务、技术）以战略为核心，战略影响三要素的发展；业务支撑战略、产品实现战略、技术实施战略。
架构的三要素之间互相支撑、互相制衡。
4、良好的架构遵循进化原则
从低级生物到高级生物、从小企业到大企业都遵循了进化的原则，大凡违背这些原则的事物都会消失、失败。架构也是如此，从简单到复杂，逐步进化，逐步发展，每经历一个痛苦阶段，都会带来质的飞跃，都能够再次适应当前的环境，从而获得生存和发展。
1）、决定系统不做成什么样子， 与决定将它做成什么样子同样重要
不去满足所有的需要， 而是让系统具备可扩展性， 使其能够向上兼容。
2）、有进有退
在架构进化的过程中，是所有要素都同步进化吗？我们看看生物的进化过程，在不同的时期有些部件会进化，有些部件会保持不变，甚至有些部件会退化，这是自然选择的结果。架构也是如此，商业环境的变化，公司战略的变化，必然要求我们作出选择 — 可能加强、可能弱化、可能维持现状。
3）、进化的要素
对于产品架构、业务架构的变化主要依赖第一要素、战略、业务指标、营收指标等商业方面的输入。
技术架构层面，具体那些要素应该变化、变多少、如何变，依赖产品和业务架构、第二要素、第三要素的组合输入或者单个输入。例如，第二要素的强壮性，要达到这一目标，可以选择增强测试、增强基础技术架构、增强信息域、加强治理等要素来实现。具体选择哪一个域中的那些要素来开展？这就需要架构依据环境做出适当的选择。
4）、控制节奏
一个好的架构进化过程，就象一曲优美的乐章、一台完美的多幕剧，让所有受众都赏心悦目，赞叹不已。
案例：Amazon 、FaceBook、EBay等，从创立之初到今天，每一家公司的架构都发生了翻天覆地的变化。
6、规划和预测
架构的规划，指在当前情况下，为一段期间内明确路线图，确保我们的进化是有序的，可控的，清晰的；以及容量的规划（系统不是无限可伸缩的，到了一定量级，必然要提前进行质变）。
架构的预测，指在量能不断变化的过程中，提前预估架构可能存在的风险，从而提前实施调整和相关的准备工作。例如：提前研究新产品、提前研究新技术等。
7、因素 — 要素作用表
备注：
A：新增表等类型的操作，不属于数据域变化的范畴【此处探讨的更多是架构一个层面的问题，例如：涉及到数据的分表，那么就属于架构范畴】。
B：用户数量变化时，对于做产品独立销售、SAAS软件等等类型的公司，其作用效果与本文所指有所不同。
C：忽略的意思是不要为其考虑专门的架构，而不是不进行对应域的相关工作。例如测试域，可以不做测试架构方面的工作，但测试却是必须的，即使只有一个人使用的软件，也要考虑测试，部署等方面的问题。
D：描述某一要素的词语”忽略”、”简单”、”仔细”、”专业”等，只表明了一种重视程度，而不是必须达到某一级别。毕竟进化时的选择，是所有外部因素集体作用的结果，而非单一因素必然促使某些要素必然发生变化。
8、一定规模下构建良好架构的一些方法
-
鼓励异步
不仅仅是技术的业务，业务也要考虑异步
-
虚拟化组件
减少物理依赖，增强部署灵活性
-
数据切分
按照某种原则分布存储数据；读写分流
-
Cache
缓存一切值得缓存的，不得不缓存的内容
-
避免cluster方案
带来的麻烦比好处还多
-
SOA思想
它是一个宝库，在架构的每个层面，都有丰富的研究成果，可供我们汲取
-
无状态
把状态都放在存储中，避免带状态的服务
-
定制部分关键技术架构组件
通过购买商业软件、使用开源软件可以极大的降低成本，同时加速技术架构的成型，不利之处是：这些通用软件总会存在不适应症、以及不能完全满足我们的非功能性指标。通过对各大网站的架构进行分析，可以发现，对于某些关键技术架构组件的定制，是解决问题的最好方式
-
技术架构标准化、简单化
技术架构尽可能标准化，避免不断引进新技术，一切以简单为原则，切忌为了技术而复杂化架构。例如，不是每家公司都必须构建和Google一样的基础技术平台，简单的技术平台一样能够为客户提供高质量的服务；架构的变化一定要遵循量变引起质变的原则，为2年的量而改造当前系统失败的几率会很高。
星期三, 08月 6th, 2008
程序员杂志采访摘录–Alipay使用SOA的概况
支付宝从05年开始规划、研究SOA；在06年开始实施第一个SOA项目，同年引入ESB产品，对SOA相关的思想、技术进行验证和探索；经过几个项目的实施，我们完成了第一阶段的规划和目标，实现了几大核心业务的SOA化，构建了一套支撑SOA的技术平台。
从理论到实践上，都积累了丰富的经验，下一阶段，我们将会在深入业务SOA的同时，不断完善和发展我们的SOA技术平台。
在采用SOA思想的过程中，我们从下面2个方面入手：
首先，从业务层面入手，用SOA思想梳理业务架构。化解业务敏捷的要求，同时支撑支付宝的开放战略。在此之前，我们在进行业务架构分析的时候，更多的是关注业务的合理性，可行性等，在业务发展的初期，这种做法能够满足我们快速开发系统，及时占领市场的需要。在05年中，我们预见到现有的业务架构，将不能支撑我们公司快速发展的需要，例如：我们的注册会员飞速奔向1亿。此时，我们就开始探讨和规划SOA思想。因此在06年，我们果断的引入SOA思想，用SOA的思想不断重构我们的业务架构。在这个过程中，随着数次公司战略的调整，业务架构都能够灵活应对，达到了业务敏捷化的目的 — 这也是SOA思想的核心。
业务架构的SOA化，是我们开展技术SOA的一个充要条件，没有这一步，我们将会非常艰难，甚至无从下手。
接着，技术层面的SOA，构建一个适合支付宝的SOA技术平台，来支撑业务SOA化的需要。针对支付宝的业务特点和要求，我们优先考虑实现如下SOA要素：
A：以服务为基本单元。技术平台提供与之对应的组件编程模型，业务层面的每一个服务，都能够方便的封装位技术层面额一个组件，例如：客户系统中的注册、登录等，都对应一个组件，每个组件都是独立的，在部署的时候，我们可以灵活选择和组合,可以依据SLA的要求，做出多种部署策略。
B：基于统一标准。在此，我们选择了ESB产品提供支撑，对外提供SOAP、REST、Hessian等标准的支持；对内统一采用定制的标准。
C：分布的能力。所有的服务都能够透明的分布，为外部消费者使用。
D：鼓励扩展。技术平台提供扩展的能力，例如：客户注册后的业务扩展点，业务部门要求依据客户注册来源、客户所在省、客户年龄等，进行不同的业务处理，而且这些业务点有些要求在事务中，有些要求在事务之外。如果每次新的需求出现，都在原有系统直接进行修改，那么不但可能破坏原有的业务，而且可能导致系统可维护性变差。提供扩展点功能，将把扩展逻辑和主体业务逻辑进行有效的隔离，能够彻底解决上面的问题。
E：支撑业务敏捷。支付宝的交易流具有流程类型多，流程过程繁杂的特点，业务流程每个月都会提出多种新的交易业务，同时我们的业务从单一交易业务流向整合型业务流发展。因此，我们引入了BPM相关的技术和工具，帮助我们方便，灵活的组合服务，定制流程。
星期六, 07月 5th, 2008
网络公司架构师角色探讨
这几天和同事聊天的时候，一张图是否能够把我们头脑的“架构”表述清楚，最终都不是很理想。原因就是架构本身就是多视角的，不同的视角，看到的图是不一样的。后来发觉以我等的能力至少需要3张图[产品视图、业务试图、技术视图]才可以表述清楚：战略与产品、业务、技术，产品与业务、技术，业务与技术。【还有一个层面的视图也很重要：数据视图】
架构师角色可以切分为数据架构师、技术架构师、业务架构师、产品架构师。
- 数据架构师
负责数据相关的架构，例如：数据库，文件数据，分布式数据架构，数据切分，数据规划，统一数据视图，数据分析，数据备份等方面的内容。
（和技术架构师一道，构件类似google的文件存储、Ebay的统一数据访问层等，对于系统伸缩性、性能、迈入云计算等价值巨大）
制定数据相关的规范、标准流程。
审核系统、项目中数据相关的内容。
- 技术架构师
关注整体系统架构，通过技术架构对业务架构提供支撑；研究基础技术，通用技术；解决系统稳定性、可靠性、性能、一致性、安全性、可用性等；关注生产率。
制定软件设计、开发、测试等方面的标准、规范、指南等。
参与核心系统设计、开发、测试等。
各类规范的审核，review。
评估系统规模，风险等。
【说明：】系统分析员不是技术架构师，但技术架构师能够胜任系统分析员的职责。
- 业务架构师
关注业务架构，对公司战略，客户需求，内部需求进行抽象，组织，规划。例如：taobao的B2C、C2C业务，会员业务，评价体系，淘宝交易等业务本质的抽象是什么的研究，业务之间的关系的组织，业务发展的规划等。技术架构师可以通过业务架构来选择技术架构，研究未来支撑业务发展的技术。
关注业务的敏捷性，能够随着战略的变化而变化。
（业务架构师抽象的业务模型，如果能够保证自身数据的一致性，异步性，那么对技术架构师将产生巨大的帮助）
制定业务相关的规范。
- 产品架构师
关注产品架构，利用核心业务包装为不同的产品或产品平台，把公司的核心业务展现给用户，把公司的战略目标具体化。例如：google的WEB搜索产品、手机搜索产品、桌面搜索产品等，同一个搜索业务，包装为不同的产品。产品架构师对产品的规划为业务架构师和同时为技术架构师提供参考。
（产品和业务最终体现了公司的战略，业务是本质，产品是外延，2者缺一不可；产品和业务的规划，发展节奏也代表了公司战略的节奏；产品和业务的发展性也代表了公司战略的持续性）
制定产品相关的规范。
- 首席架构师
制定公司的长期技术路线图。
是公司技术方向和技术组合的重要决策者。
【其它架构师角色】
对于大型网络公司来说，系统管理员的角色的职责并未完全被技术架构师代替。
测试架构师，（看看一个招聘要求：开发和设计测试框架； 纵横全局的考虑产品的功能及非功能需求，设计高精的测试系统；负责研发特定的测试技术；提高整体测试效率；领导公司测试技术的发展和测试策略的方向；前瞻性的考虑未来的版本的测试策略和技术；计划 / 设计测试平台，关注着产品的测试过程；具备测试技术、测试方法学上雄厚的知识。）
【参考】
《谁来当首席架构师？》的相关内容
架构师
10条你不需要软件架构师的理由
软件架构师_21ks.net专题辅导资料
系统分析员、系统架构师、项目经理的区别
什么样的产品人才是人才
星期一, 06月 30th, 2008
良好的编程习惯是成长的助推剂
近来看到、听到一些很小的问题，却导致了系统故障（甚至更严重的问题）。
- 案例1：等号（==）导致的损失
- 案例2：少传递一个参数导致的损失
- 案例3：默认返回结果的乐观，导致的损失
- 案例4：偶然停止的一个系统，导致系统停机
- 案例5：2个参数没有设置，导致外部系统故障的内部传递
- 案例6：大小写，导致某类业务失败
- 等等
事后看这些问题，发现都很简单，都是由于程序员的粗心导致的。或有有人会说，我们应当允许犯错误，我也是非常认可的，但对于一个企业来说却是非常可怕的，上百个程序员，每人都犯一次这类错误，恐怕企业会有些受不了。
如何规避这些问题哪？
- 制度保证
- 测试保证
- 程序员良好的编程习惯
通过下面几个例子，简单说明良好编程习惯对成长的助推作用。
首先，通过观察，发现上面所列的问题，都是一些编程习惯导致不是很好的人身上发生的。
其次，通过和一些同事交流，虽然他们自己没有遇到过这类问题，但良好的编程习惯帮助他们避免了这类问题以及克服了其它困难。
再次，同样一起进入公司的新毕业的学生，工作时间、加班时间也一样多，1年后，发展却非常不同。通过观察，我发现：排处天然因素，后天因素中很重要的一点就是良好的编程习惯帮助他们获得了成长。
良好的编成习惯包含很多方面，综合我身边这类人的特质，总结了下面几点：
- 坚决按照业界认可（或公司认可）的编程风格编写代码
- 开发、调试、测试过程中遇到的问题，不是简单的解决问题，而是进行深入的思考，挖掘现象背后的基础层面的东西
- 对于别人、外界出现的一些BUG，不是简单的听听即可，而是进行试验，思考
- 对于别人无法解决的BUG，总是尝试各类方法，不解决问题，决不罢休
- 不断总结-〉实践-〉再总结
星期日, 06月 29th, 2008
Java Enum小心使用，它可能增加系统耦合性
关于在SOA环境中使用Java Enum的一些经验已经在《服务化的行军中：Enum使用，快乐的痛苦》一文中进行了讲述。
随着项目的深入，在某些环节使用Enum的不爽之处，上升为一些设计方面的选择问题。
- Enum不适合作为通用类的属性来使用
在我们的代码中，我看到如下一个情况，有关类：UserPrincipal，它被整个分布式系统中的所有系统共同使用，从包的放置位置：net.esbzone.comm.security就可以看出它的通用性。突然某天，看到有同学在这个类加入了一个Enum属性，这个Enum属性还是另外一个业务系统B内部定义的一个通用常量【这个常量的确很是通用，表示用户类型】。这个例子，首先导致UserPrincipal与业务系统B产生了紧耦合，间接导致所有系统与业务系统B产生了耦合；其次即使它定义在net.esbzone.comm.security包中，也间接导致UserPrincipal与具体业务产生了关联，会增强外部系统对Enum的耦合度，从而削弱了UserPrincipal的独立性；此外一旦Enum发生变化，所有依赖与它的业务系统都要发生变化，代码依赖级别的变化。
往往，Enum的业务语义太强，与场景的关联性太密切，一旦环境发生了变化，Enum的值就可能发生变化，从而导致使用它的业务域对象也可能要发生变化。
使用Enum作为通用类的属性，制约了该类的通用性。
【注意：】在封闭系统内部是非常适合使用Enum，它会增强代码的可读性，减少维护成本，降低风险。
- Enum不适合作为服务接口的参数来用
首先是序列化的风险。
其次Enum增强了系统的耦合性，如果只是接口耦合，那么可以通过WS，HTTP POST等方式来降耦。如果使用了Enum之后，我们进一步增加了对Enum这种特殊类型的处理【大部分标准化协议和现代变成语言，都支持原子类型，对象类型，集合类型，但对Enum的支持却各有所不同】，这就增加了耦合性。此外，此时对于一个使用者要面对多个服务提供者的时候，如果遇到这种情况就会更加痛苦不堪。
再次，Enum在接口层使用，制约了扩展性。当增加一个新的业务常量时，需要修改Enum，此时它的WSDL文件也会发生变化【这点很头痛】，想到于修改了接口描述文件。
最后，我们从业务协议设计的角度来看，我们需要的只是原子数据类型，而不是Enum这么强的一个对象类型。
星期六, 06月 7th, 2008
在这儿，一个程序员需要学习的东西的目录
在软件开发过程中，难免会遇到遇到各种问题，随着时间的流逝，居然形成了一些文字化的东西和一些口传心授的东西—我们称呼曰“文档、标准”。随着人员的增多，并发项目也很多，这些东西，对我们产生的影响力也越来越大。新人来时，每每言传身教之后，都会有所遗漏。的确，在这儿，做一个好的程序员学的东西也真够多的，累！！何况，这些东西还在不断增加中，苦！！
最容易出现问题的技术点、业务点的说明。时刻牢记之，否则就会出问题。
项目管理流程文档。没有标准的一个玩意，玩法多样。
<<需求分析模板>>文档。
<<系统分析模板>>文档。尽可能的全面，结果反而导致无从下手。<<架构分析模板>>文档。
<<软件设计模板>>文档
程序开发过程中，要严格按照相关业务准则执行，当程序准则违背业务准则时，以业务准则为主。
《产品编码风格》文档。
《产品技术体系结构》文档。
《WEB层开发规范和指导手册》文档。
《数据存储规范和指导手册》文档。
《服务层指导手册》文档。
《领域层指导手册》文档。
《业务逻辑层指导手册》文档。
《服务化业务指导手册》文档。
《软件配置指导手册》文档。
《分布式服务使用规范》文档。
《内部编码约定》文档。
《对象XML序列化规范》文档。
《数字、时间使用规范》文档。
《权限定义、使用、管理指导手册》文档。
《日志编写指导手册》文档。
《常量、枚举、国际化指导手册》文档。
《安全编码指导目录》文档。
《批量任务指导手册》文档。
《应用系统健康检查指导手册》文档。
《数据库开发和使用规范》文档。
《代码Review指导目录》文档。
《单元测试指导手册》文档。
《系统回归测试指导手册》文档。
《系统集成测试指导手册》文档。
<<项目发布计划模板>>文档。
《源代码使用和管理规范》文档。
涉及到各个业务层面的规则文档。
星期四, 06月 5th, 2008
小插曲：一种业务依赖的思考
存在业务A，例如IM工具绑定，用户只有绑带了IM才能使用我们的新闻订阅服务；后来，基于IM工具，我们又开发了交易产品。业务规定：如果用户取消了IM工具绑定，那么IM交易产品也取消。从数据上看，IM交易产品，要是适用IM绑定产品的信息，存在数据上的依赖。
起初系统部署在一个JVM内，当取消IM绑定的时候，也会随着取消IM交易协议（用户选择适用IM交易产品的过程，从业务本质看是客户与我们的签订协议过程，因此取消也是一个协议过程，为什么适用这么复杂的概念？在程序级别就是一个删除或更新。）。
现在2个产品部署在不同服务器上，当取消IM绑定的时候，是否需要取消IM交易协议，在那个点来取消，就引起了争论。
如图所示：第一阶段程序都是Jar依赖，可以认为在一个JVM中，执行取消IM绑定倒也方便。第二阶段，业务分布式部署之后，就对IM交易协议如何处理引发争议。
注：IM绑定、IM交易、客户平台、管理平台都是系统。
观点1：取消IM绑定，IM交易协议也取消。解决方法：客户平台、管理平台直接调用IM绑定、IM交易。
观点2：取消IM绑定，IM交易协议也取消。解决方法：客户平台、管理平台直接调用IM绑定，IM绑定调用IM交易。
观点3：取消IM绑定，IM交易协议也取消。解决方法：客户平台、管理平台直接调用IM绑定，IM绑定利用ESB的可靠Pub/Sub机制触发IM交易。
观点4：取消IM绑定，忽略IM交易协议。由IM交易产品自己获取IM绑定状态，从而做出业务处理。
1-3观点，从业务上是一致的，4是独立的。
从用户的角度来说，好像只要最终不能适用IM交易，系统目标就完成，对于做业务的人这样看问题是否合适？也可以，毕竟是2个独立系统吗，只要数据上作一次判读，就不会有任何问题，这个解释也可以接受的。典型程序员思维，系统作出正确表现即可。
从OO的角度来看，IM交易的是IM绑定的扩展，本体不存在，扩展存在还有什么意义？
从业务角度看，用户2次绑定，意味着发生了2次签约，第一次和第二次是否可以认为是一个签约，如果不是，IM交易协议以谁为依据。对于IM交易系统，它从IM绑定系统获取数据，不是为了验证是否存在IM绑定，而是要验证合约与数据是否一致。从这个角度看，IM绑定取消，意味着IM交易的自动失效。
[注：在单系统的时候，由于方便，往往不会像太多，反正方便，也没有人有啥疑义；一旦分布之后，业务独立切分了，大家都麻烦了，就开始思考了，此时采用什么方式往往由业务本性（什么是业务本质=？本性，我也定义不清楚）来决定。]
既然皮之不存，毛将焉附？1，2，3好像都满足，此时，我们在从业务出发，就会发现2，3更合乎业务，触发IM交易取消的事件不是用户直接发出的指令，而是IM绑定发生业务变化之后，通知它的粉丝（依赖着）。
2与3的选择，从架构扩展性，SOA治理，服务化的角度来看，选择3为佳。
有以下几个细的出发点供参考：
- 服务化，就是要确保每个独立业务的稳定性，采用观点2，一旦再有一个IM物流业务，就需要修改IM绑定业务。
- 大规模群集环境下，直接xfire之类的框架调用，需要独立引入软件负载，或者采用硬件负载。
- IM绑定和IM交易可以接受有限制异步模式，这对于性能，有很多帮助。如果IM交易，又依赖其它业务，同步访问的稳定性和性能会受到影响，事务处理也头痛。
【参考：SOA，想说爱你不容易】
- SOA化之后，对服务的监控、治理要求会逐步提高，由统一的一个ESB产品来解决，会更好一些。
对于业务性比较强的公司和项目，多一些业务本质上的思考，少一些程序、数据角度的解决方案，带来的益处还是很多的。
对于这一类的业务，至于选择哪个方案，还要结合业务量，业务发展速度，成本，时间，人力等多个角度来衡量，对于我们合适的方案未必适合每一个人。
构建架构的思考
（说明：以下内容仅仅是一种思考，而不是某家公司的具体内容，在此过程中，参考了多篇 DBA Notes上关于一些公司互联网架构的介绍，在此表示感谢！同时参考了其它一些关于架构介绍的文章。很欣赏我同事[程立]的一句话，用中国古典文化阐释架构的源和重要性 — 老子说”道生一、一生二、二生三、三生万物”。在业务愿景的技术实现过程中，假设”道”为愿景、一为方向、二为战略的话，三就应该是架构了，架构既出，万物化生可矣。”）
关于什么是架构，已经有很多文章在讨论了，本文不予以探讨。
关于架构的类型，业界的定义也各不相同，《架构的类型》对这个问题进行了探讨，可供参考。
此处所探讨的架构可能包含了企业架构、系统架构、软件架构、信息架构、SOA架构等方面的部分要素，所适用的行业，也仅限于互联网行业。在此，引出了构建良好架构的第一个基本原则：依据业务特征选择架构。例如，Amazon、EBay、FaceBook、YouTube等互联网企业的架构都非常的不同，每家公司都有自己独特的架构特征，首要因素就在于第一要素。
之所以称之为哲学原则，首先它们比较虚，就像黑洞那么虚；其次度量起来比较困难，没有一个统一的标准，也很难定义标准，例如不同机构对客户满意的定义就不一样；再次它们的确很通用，在架构的各个阶段、各个层面、各种粒度都适用。
它包含如下子元素：
- 使客户(所有直接或间接使用这个系统的人都是客户)满意 – 功能、质量、使用、体验
- 良好的投资回报率 — 复用、免费产品、成型产品
- 足够敏捷，适应业务的发展，且能够快速推出新业务 – 可发展性
- 支撑企业核心竞争力
- 简单又实用
- 强壮又稳定 （ 架构设计必须考虑到故障—业务故障的可恢复性、技术故障的可恢复性，非常状态的故障：电力不足、机房断网、自然灾害等，冗余和错误恢复也是达到稳定的必要手段）
- 术语一致性（有点像统一思想、统一口径）
- 可维护性
- 支持未来的发展
- 对运营友好 （尽可能自动化，是对运营不错的支持）
“量变是指事物单 纯数量上的增加或减少，事物保持其质的稳定性。质变是指事物根本性质的变化，在这阶段，事物处于剧烈的变化之中，其平衡静止被打破，旧的事物转化为新事 物。事物的变化总是先从量变开始的，待量变积累到一定程度后，才会发生质变，其中量变是质变的必然前提，质变是量变的必然结果，量变→质变→新的量变是事 物发展的基本规律”。这条哲学规律同样适用与系统架构，每次大的系统架构的变化，背后的动因都是”量”引起的【类似window这样的系统架构变化的动因，不在此处的探讨】。在互联网领域，如下主体的量起到很大的作用：
基本量：
- 用户 — 总量/日访问量/并发量/增长率
- 访问量（PV） — 日访问量/并发量/响应周期
- 产品 — 数量/业务领域量
被动量：
- 业务数据 — 历史总量/日变化量/并发量/增长率
- 系统日志 — 一段区间总量/日生成量
- 业务日志 — 历史总量/日变化量/并发量
- 事务量 — 日变化量/并发量/响应周期
- 外部网络 — 流量/并发量
- 内部网络 —并发量
- 网络连接 —并发量
- 图片 —总量/日访问量/并发量/增长率
- 项目【包括日常升级、日常BUG维护】 — 平均开发周期/项目组成员增长率/测试周期/发布时间
- BUG — 确定原因周期/响应周期
- 系统服务（SOA角度的服务） — 总量
- 设备 — 总量
- 内部抱怨 — 声贝的大小
- 停机维护 — 次数/时间
基本量是基础，它驱动被动量的变化，例如用户，日访问量会引起业务数据、网络连接等的变化，基本量的变化对架构的影响最大，时刻关注基本量的升降。
【注意：】不用业务领域，重点关注的主体略有差别
上面是针对互联网产品的一种架构【产品架构和业务架构是都需要针对自身的特点进行划分，不具有通用性】。
- 产品架构的目的
能够描绘当前产品的关系、分类；
能够体现公司的核心价值、核心竞争力；
能够实现公司的战略意图；
能够支撑现有产品的管理和标准化进程、以及未来产品的规划；
能够指导产品的可持续发展、创新；
为技术架构提供产品输入。
- 业务架构的目的
能够描绘当前业务的关系；
能够支撑公司的战略；
能够支撑产品在既定方向上发展；
能够支撑业务的发展和敏捷；
为技术架构提供业务输入。
- 技术架构的目的
能够描述当前的IT状况；
能够支撑对产品的发展；
能够为客户提供高质量的服务【非功能性方面的需求】。
为技术架构选择的几个子架构域：
-
信息域
此处的信息特指用户交互层面的信息、跨系统的信息、内部管理的信息。本域内关注用户信息展示、信息聚合、信息共享、信息交换、信息分析和挖掘等。
-
基础技术域
支撑IT的基础设施，该域包含硬件基础、系统基础、应用基础环境、通用技术（例如：工作流、ESB、搜索等）、程序驻留环境（类似FaceBook的开放平台）等。
-
数据域
支撑数据的存储（数据库存储、文件存储【例如：BigTable】、甚至存储在S3中）、访问（透明统一的访问）、分布（物理分布、水平切分数据、垂直切分数据）、缓存、备份、归档等。
-
部署域
支撑系统（此处单指一个独立的物理整体，例如运行在一个JVM上的所有的内容）和服务（单指SOA服务）的运行、管理、发布、分布（同城、异地）、日志等。
-
治理域
为公司业务的运营提供不同粒度的（硬件、系统粒度、产品粒度、服务粒度、客户粒度等）监控、报警、控制、隔离，以及服务的版本管理等。
-
安全域
为公司业务的安全提供硬件、软件、业务等方面的支撑。
-
测试域
为产品提供测试环境、生产环境、沙箱环境、性能环境等的支撑。
-
分析域
支撑公司运营、管理、客户分析、智能系统等（从简单的URL分析、到服务路径的分析、定向客户分析等）。
架构的三要素（产品、业务、技术）以战略为核心，战略影响三要素的发展；业务支撑战略、产品实现战略、技术实施战略。
架构的三要素之间互相支撑、互相制衡。
从低级生物到高级生物、从小企业到大企业都遵循了进化的原则，大凡违背这些原则的事物都会消失、失败。架构也是如此，从简单到复杂，逐步进化，逐步发展，每经历一个痛苦阶段，都会带来质的飞跃，都能够再次适应当前的环境，从而获得生存和发展。
1）、决定系统不做成什么样子， 与决定将它做成什么样子同样重要
不去满足所有的需要， 而是让系统具备可扩展性， 使其能够向上兼容。
2）、有进有退
在架构进化的过程中，是所有要素都同步进化吗？我们看看生物的进化过程，在不同的时期有些部件会进化，有些部件会保持不变，甚至有些部件会退化，这是自然选择的结果。架构也是如此，商业环境的变化，公司战略的变化，必然要求我们作出选择 — 可能加强、可能弱化、可能维持现状。
3）、进化的要素
对于产品架构、业务架构的变化主要依赖第一要素、战略、业务指标、营收指标等商业方面的输入。
技术架构层面，具体那些要素应该变化、变多少、如何变，依赖产品和业务架构、第二要素、第三要素的组合输入或者单个输入。例如，第二要素的强壮性，要达到这一目标，可以选择增强测试、增强基础技术架构、增强信息域、加强治理等要素来实现。具体选择哪一个域中的那些要素来开展？这就需要架构依据环境做出适当的选择。
4）、控制节奏
一个好的架构进化过程，就象一曲优美的乐章、一台完美的多幕剧，让所有受众都赏心悦目，赞叹不已。
案例：Amazon 、FaceBook、EBay等，从创立之初到今天，每一家公司的架构都发生了翻天覆地的变化。
架构的规划，指在当前情况下，为一段期间内明确路线图，确保我们的进化是有序的，可控的，清晰的；以及容量的规划（系统不是无限可伸缩的，到了一定量级，必然要提前进行质变）。
架构的预测，指在量能不断变化的过程中，提前预估架构可能存在的风险，从而提前实施调整和相关的准备工作。例如：提前研究新产品、提前研究新技术等。
备注：
A：新增表等类型的操作，不属于数据域变化的范畴【此处探讨的更多是架构一个层面的问题，例如：涉及到数据的分表，那么就属于架构范畴】。
B：用户数量变化时，对于做产品独立销售、SAAS软件等等类型的公司，其作用效果与本文所指有所不同。
C：忽略的意思是不要为其考虑专门的架构，而不是不进行对应域的相关工作。例如测试域，可以不做测试架构方面的工作，但测试却是必须的，即使只有一个人使用的软件，也要考虑测试，部署等方面的问题。
D：描述某一要素的词语”忽略”、”简单”、”仔细”、”专业”等，只表明了一种重视程度，而不是必须达到某一级别。毕竟进化时的选择，是所有外部因素集体作用的结果，而非单一因素必然促使某些要素必然发生变化。
-
鼓励异步
不仅仅是技术的业务，业务也要考虑异步
-
虚拟化组件
减少物理依赖，增强部署灵活性
-
数据切分
按照某种原则分布存储数据；读写分流
-
Cache
缓存一切值得缓存的，不得不缓存的内容
-
避免cluster方案
带来的麻烦比好处还多
-
SOA思想
它是一个宝库，在架构的每个层面，都有丰富的研究成果，可供我们汲取
-
无状态
把状态都放在存储中，避免带状态的服务
-
定制部分关键技术架构组件
通过购买商业软件、使用开源软件可以极大的降低成本，同时加速技术架构的成型，不利之处是：这些通用软件总会存在不适应症、以及不能完全满足我们的非功能性指标。通过对各大网站的架构进行分析，可以发现，对于某些关键技术架构组件的定制，是解决问题的最好方式
-
技术架构标准化、简单化
技术架构尽可能标准化，避免不断引进新技术，一切以简单为原则，切忌为了技术而复杂化架构。例如，不是每家公司都必须构建和Google一样的基础技术平台，简单的技术平台一样能够为客户提供高质量的服务；架构的变化一定要遵循量变引起质变的原则，为2年的量而改造当前系统失败的几率会很高。
程序员杂志采访摘录–Alipay使用SOA的概况
支付宝从05年开始规划、研究SOA；在06年开始实施第一个SOA项目，同年引入ESB产品，对SOA相关的思想、技术进行验证和探索；经过几个项目的实施，我们完成了第一阶段的规划和目标，实现了几大核心业务的SOA化，构建了一套支撑SOA的技术平台。
从理论到实践上，都积累了丰富的经验，下一阶段，我们将会在深入业务SOA的同时，不断完善和发展我们的SOA技术平台。
在采用SOA思想的过程中，我们从下面2个方面入手：
首先，从业务层面入手，用SOA思想梳理业务架构。化解业务敏捷的要求，同时支撑支付宝的开放战略。在此之前，我们在进行业务架构分析的时候，更多的是关注业务的合理性，可行性等，在业务发展的初期，这种做法能够满足我们快速开发系统，及时占领市场的需要。在05年中，我们预见到现有的业务架构，将不能支撑我们公司快速发展的需要，例如：我们的注册会员飞速奔向1亿。此时，我们就开始探讨和规划SOA思想。因此在06年，我们果断的引入SOA思想，用SOA的思想不断重构我们的业务架构。在这个过程中，随着数次公司战略的调整，业务架构都能够灵活应对，达到了业务敏捷化的目的 — 这也是SOA思想的核心。
业务架构的SOA化，是我们开展技术SOA的一个充要条件，没有这一步，我们将会非常艰难，甚至无从下手。
接着，技术层面的SOA，构建一个适合支付宝的SOA技术平台，来支撑业务SOA化的需要。针对支付宝的业务特点和要求，我们优先考虑实现如下SOA要素：
A：以服务为基本单元。技术平台提供与之对应的组件编程模型，业务层面的每一个服务，都能够方便的封装位技术层面额一个组件，例如：客户系统中的注册、登录等，都对应一个组件，每个组件都是独立的，在部署的时候，我们可以灵活选择和组合,可以依据SLA的要求，做出多种部署策略。
B：基于统一标准。在此，我们选择了ESB产品提供支撑，对外提供SOAP、REST、Hessian等标准的支持；对内统一采用定制的标准。
C：分布的能力。所有的服务都能够透明的分布，为外部消费者使用。
D：鼓励扩展。技术平台提供扩展的能力，例如：客户注册后的业务扩展点，业务部门要求依据客户注册来源、客户所在省、客户年龄等，进行不同的业务处理，而且这些业务点有些要求在事务中，有些要求在事务之外。如果每次新的需求出现，都在原有系统直接进行修改，那么不但可能破坏原有的业务，而且可能导致系统可维护性变差。提供扩展点功能，将把扩展逻辑和主体业务逻辑进行有效的隔离，能够彻底解决上面的问题。
E：支撑业务敏捷。支付宝的交易流具有流程类型多，流程过程繁杂的特点，业务流程每个月都会提出多种新的交易业务，同时我们的业务从单一交易业务流向整合型业务流发展。因此，我们引入了BPM相关的技术和工具，帮助我们方便，灵活的组合服务，定制流程。
网络公司架构师角色探讨
这几天和同事聊天的时候，一张图是否能够把我们头脑的“架构”表述清楚，最终都不是很理想。原因就是架构本身就是多视角的，不同的视角，看到的图是不一样的。后来发觉以我等的能力至少需要3张图[产品视图、业务试图、技术视图]才可以表述清楚：战略与产品、业务、技术，产品与业务、技术，业务与技术。【还有一个层面的视图也很重要：数据视图】
架构师角色可以切分为数据架构师、技术架构师、业务架构师、产品架构师。
- 数据架构师
- 技术架构师
- 业务架构师
- 产品架构师
- 首席架构师
负责数据相关的架构，例如：数据库，文件数据，分布式数据架构，数据切分，数据规划，统一数据视图，数据分析，数据备份等方面的内容。
（和技术架构师一道，构件类似google的文件存储、Ebay的统一数据访问层等，对于系统伸缩性、性能、迈入云计算等价值巨大）
制定数据相关的规范、标准流程。
审核系统、项目中数据相关的内容。
关注整体系统架构，通过技术架构对业务架构提供支撑；研究基础技术，通用技术；解决系统稳定性、可靠性、性能、一致性、安全性、可用性等；关注生产率。
制定软件设计、开发、测试等方面的标准、规范、指南等。
参与核心系统设计、开发、测试等。
各类规范的审核，review。
评估系统规模，风险等。
【说明：】系统分析员不是技术架构师，但技术架构师能够胜任系统分析员的职责。
关注业务架构，对公司战略，客户需求，内部需求进行抽象，组织，规划。例如：taobao的B2C、C2C业务，会员业务，评价体系，淘宝交易等业务本质的抽象是什么的研究，业务之间的关系的组织，业务发展的规划等。技术架构师可以通过业务架构来选择技术架构，研究未来支撑业务发展的技术。
关注业务的敏捷性，能够随着战略的变化而变化。
（业务架构师抽象的业务模型，如果能够保证自身数据的一致性，异步性，那么对技术架构师将产生巨大的帮助）
制定业务相关的规范。
关注产品架构，利用核心业务包装为不同的产品或产品平台，把公司的核心业务展现给用户，把公司的战略目标具体化。例如：google的WEB搜索产品、手机搜索产品、桌面搜索产品等，同一个搜索业务，包装为不同的产品。产品架构师对产品的规划为业务架构师和同时为技术架构师提供参考。
（产品和业务最终体现了公司的战略，业务是本质，产品是外延，2者缺一不可；产品和业务的规划，发展节奏也代表了公司战略的节奏；产品和业务的发展性也代表了公司战略的持续性）
制定产品相关的规范。
制定公司的长期技术路线图。
是公司技术方向和技术组合的重要决策者。
【其它架构师角色】
对于大型网络公司来说，系统管理员的角色的职责并未完全被技术架构师代替。
测试架构师，（看看一个招聘要求：开发和设计测试框架； 纵横全局的考虑产品的功能及非功能需求，设计高精的测试系统；负责研发特定的测试技术；提高整体测试效率；领导公司测试技术的发展和测试策略的方向；前瞻性的考虑未来的版本的测试策略和技术；计划 / 设计测试平台，关注着产品的测试过程；具备测试技术、测试方法学上雄厚的知识。）
【参考】
《谁来当首席架构师？》的相关内容
架构师
10条你不需要软件架构师的理由
软件架构师_21ks.net专题辅导资料
系统分析员、系统架构师、项目经理的区别
什么样的产品人才是人才
良好的编程习惯是成长的助推剂
近来看到、听到一些很小的问题，却导致了系统故障（甚至更严重的问题）。
- 案例1：等号（==）导致的损失
- 案例2：少传递一个参数导致的损失
- 案例3：默认返回结果的乐观，导致的损失
- 案例4：偶然停止的一个系统，导致系统停机
- 案例5：2个参数没有设置，导致外部系统故障的内部传递
- 案例6：大小写，导致某类业务失败
- 等等
事后看这些问题，发现都很简单，都是由于程序员的粗心导致的。或有有人会说，我们应当允许犯错误，我也是非常认可的，但对于一个企业来说却是非常可怕的，上百个程序员，每人都犯一次这类错误，恐怕企业会有些受不了。
如何规避这些问题哪？
- 制度保证
- 测试保证
- 程序员良好的编程习惯
通过下面几个例子，简单说明良好编程习惯对成长的助推作用。
首先，通过观察，发现上面所列的问题，都是一些编程习惯导致不是很好的人身上发生的。
其次，通过和一些同事交流，虽然他们自己没有遇到过这类问题，但良好的编程习惯帮助他们避免了这类问题以及克服了其它困难。
再次，同样一起进入公司的新毕业的学生，工作时间、加班时间也一样多，1年后，发展却非常不同。通过观察，我发现：排处天然因素，后天因素中很重要的一点就是良好的编程习惯帮助他们获得了成长。
良好的编成习惯包含很多方面，综合我身边这类人的特质，总结了下面几点：
- 坚决按照业界认可（或公司认可）的编程风格编写代码
- 开发、调试、测试过程中遇到的问题，不是简单的解决问题，而是进行深入的思考，挖掘现象背后的基础层面的东西
- 对于别人、外界出现的一些BUG，不是简单的听听即可，而是进行试验，思考
- 对于别人无法解决的BUG，总是尝试各类方法，不解决问题，决不罢休
- 不断总结-〉实践-〉再总结
Java Enum小心使用，它可能增加系统耦合性
关于在SOA环境中使用Java Enum的一些经验已经在《服务化的行军中：Enum使用，快乐的痛苦》一文中进行了讲述。
随着项目的深入，在某些环节使用Enum的不爽之处，上升为一些设计方面的选择问题。
- Enum不适合作为通用类的属性来使用
- Enum不适合作为服务接口的参数来用
在我们的代码中，我看到如下一个情况，有关类：UserPrincipal，它被整个分布式系统中的所有系统共同使用，从包的放置位置：net.esbzone.comm.security就可以看出它的通用性。突然某天，看到有同学在这个类加入了一个Enum属性，这个Enum属性还是另外一个业务系统B内部定义的一个通用常量【这个常量的确很是通用，表示用户类型】。这个例子，首先导致UserPrincipal与业务系统B产生了紧耦合，间接导致所有系统与业务系统B产生了耦合；其次即使它定义在net.esbzone.comm.security包中，也间接导致UserPrincipal与具体业务产生了关联，会增强外部系统对Enum的耦合度，从而削弱了UserPrincipal的独立性；此外一旦Enum发生变化，所有依赖与它的业务系统都要发生变化，代码依赖级别的变化。
往往，Enum的业务语义太强，与场景的关联性太密切，一旦环境发生了变化，Enum的值就可能发生变化，从而导致使用它的业务域对象也可能要发生变化。
使用Enum作为通用类的属性，制约了该类的通用性。
【注意：】在封闭系统内部是非常适合使用Enum，它会增强代码的可读性，减少维护成本，降低风险。
首先是序列化的风险。
其次Enum增强了系统的耦合性，如果只是接口耦合，那么可以通过WS，HTTP POST等方式来降耦。如果使用了Enum之后，我们进一步增加了对Enum这种特殊类型的处理【大部分标准化协议和现代变成语言，都支持原子类型，对象类型，集合类型，但对Enum的支持却各有所不同】，这就增加了耦合性。此外，此时对于一个使用者要面对多个服务提供者的时候，如果遇到这种情况就会更加痛苦不堪。
再次，Enum在接口层使用，制约了扩展性。当增加一个新的业务常量时，需要修改Enum，此时它的WSDL文件也会发生变化【这点很头痛】，想到于修改了接口描述文件。
最后，我们从业务协议设计的角度来看，我们需要的只是原子数据类型，而不是Enum这么强的一个对象类型。
在这儿，一个程序员需要学习的东西的目录
在软件开发过程中，难免会遇到遇到各种问题，随着时间的流逝，居然形成了一些文字化的东西和一些口传心授的东西—我们称呼曰“文档、标准”。随着人员的增多，并发项目也很多，这些东西，对我们产生的影响力也越来越大。新人来时，每每言传身教之后，都会有所遗漏。的确，在这儿，做一个好的程序员学的东西也真够多的，累！！何况，这些东西还在不断增加中，苦！！
最容易出现问题的技术点、业务点的说明。时刻牢记之，否则就会出问题。
项目管理流程文档。没有标准的一个玩意，玩法多样。
<<需求分析模板>>文档。
<<系统分析模板>>文档。尽可能的全面，结果反而导致无从下手。<<架构分析模板>>文档。
<<软件设计模板>>文档
程序开发过程中，要严格按照相关业务准则执行，当程序准则违背业务准则时，以业务准则为主。
《产品编码风格》文档。
《产品技术体系结构》文档。
《WEB层开发规范和指导手册》文档。
《数据存储规范和指导手册》文档。
《服务层指导手册》文档。
《领域层指导手册》文档。
《业务逻辑层指导手册》文档。
《服务化业务指导手册》文档。
《软件配置指导手册》文档。
《分布式服务使用规范》文档。
《内部编码约定》文档。
《对象XML序列化规范》文档。
《数字、时间使用规范》文档。
《权限定义、使用、管理指导手册》文档。
《日志编写指导手册》文档。
《常量、枚举、国际化指导手册》文档。
《安全编码指导目录》文档。
《批量任务指导手册》文档。
《应用系统健康检查指导手册》文档。
《数据库开发和使用规范》文档。
《代码Review指导目录》文档。
《单元测试指导手册》文档。
《系统回归测试指导手册》文档。
《系统集成测试指导手册》文档。
<<项目发布计划模板>>文档。
《源代码使用和管理规范》文档。
涉及到各个业务层面的规则文档。
小插曲：一种业务依赖的思考
存在业务A，例如IM工具绑定，用户只有绑带了IM才能使用我们的新闻订阅服务；后来，基于IM工具，我们又开发了交易产品。业务规定：如果用户取消了IM工具绑定，那么IM交易产品也取消。从数据上看，IM交易产品，要是适用IM绑定产品的信息，存在数据上的依赖。
起初系统部署在一个JVM内，当取消IM绑定的时候，也会随着取消IM交易协议（用户选择适用IM交易产品的过程，从业务本质看是客户与我们的签订协议过程，因此取消也是一个协议过程，为什么适用这么复杂的概念？在程序级别就是一个删除或更新。）。
现在2个产品部署在不同服务器上，当取消IM绑定的时候，是否需要取消IM交易协议，在那个点来取消，就引起了争论。
如图所示：第一阶段程序都是Jar依赖，可以认为在一个JVM中，执行取消IM绑定倒也方便。第二阶段，业务分布式部署之后，就对IM交易协议如何处理引发争议。
注：IM绑定、IM交易、客户平台、管理平台都是系统。
观点1：取消IM绑定，IM交易协议也取消。解决方法：客户平台、管理平台直接调用IM绑定、IM交易。
观点2：取消IM绑定，IM交易协议也取消。解决方法：客户平台、管理平台直接调用IM绑定，IM绑定调用IM交易。
观点3：取消IM绑定，IM交易协议也取消。解决方法：客户平台、管理平台直接调用IM绑定，IM绑定利用ESB的可靠Pub/Sub机制触发IM交易。
观点4：取消IM绑定，忽略IM交易协议。由IM交易产品自己获取IM绑定状态，从而做出业务处理。
1-3观点，从业务上是一致的，4是独立的。
从用户的角度来说，好像只要最终不能适用IM交易，系统目标就完成，对于做业务的人这样看问题是否合适？也可以，毕竟是2个独立系统吗，只要数据上作一次判读，就不会有任何问题，这个解释也可以接受的。典型程序员思维，系统作出正确表现即可。
从OO的角度来看，IM交易的是IM绑定的扩展，本体不存在，扩展存在还有什么意义？
从业务角度看，用户2次绑定，意味着发生了2次签约，第一次和第二次是否可以认为是一个签约，如果不是，IM交易协议以谁为依据。对于IM交易系统，它从IM绑定系统获取数据，不是为了验证是否存在IM绑定，而是要验证合约与数据是否一致。从这个角度看，IM绑定取消，意味着IM交易的自动失效。
[注：在单系统的时候，由于方便，往往不会像太多，反正方便，也没有人有啥疑义；一旦分布之后，业务独立切分了，大家都麻烦了，就开始思考了，此时采用什么方式往往由业务本性（什么是业务本质=？本性，我也定义不清楚）来决定。]
既然皮之不存，毛将焉附？1，2，3好像都满足，此时，我们在从业务出发，就会发现2，3更合乎业务，触发IM交易取消的事件不是用户直接发出的指令，而是IM绑定发生业务变化之后，通知它的粉丝（依赖着）。
2与3的选择，从架构扩展性，SOA治理，服务化的角度来看，选择3为佳。
有以下几个细的出发点供参考：
- 服务化，就是要确保每个独立业务的稳定性，采用观点2，一旦再有一个IM物流业务，就需要修改IM绑定业务。
- 大规模群集环境下，直接xfire之类的框架调用，需要独立引入软件负载，或者采用硬件负载。
- IM绑定和IM交易可以接受有限制异步模式，这对于性能，有很多帮助。如果IM交易，又依赖其它业务，同步访问的稳定性和性能会受到影响，事务处理也头痛。
【参考：SOA，想说爱你不容易】 - SOA化之后，对服务的监控、治理要求会逐步提高，由统一的一个ESB产品来解决，会更好一些。
对于业务性比较强的公司和项目，多一些业务本质上的思考，少一些程序、数据角度的解决方案，带来的益处还是很多的。
对于这一类的业务，至于选择哪个方案，还要结合业务量，业务发展速度，成本，时间，人力等多个角度来衡量，对于我们合适的方案未必适合每一个人。
