星期三, 03月 4th, 2009
产品领域探讨(互联网领域)
该文主要探讨了如下一些问题：产品与业务的关系是什么；用事物本质来理解互联网产品；产品风格与产品品质是啥关系；产品服务质量和产品品质是啥关系；产品风格与用户需求；产品品质转换为产品需求；业务分析师的价值；产品风格与架构风格；产品分类和产品标识；产品与产品模型；产品与商品。该文也是希望抛个砖头，和大家一起探讨这些产品领域。详细请进。
星期五, 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，总是尝试各类方法，不解决问题，决不罢休
- 不断总结-〉实践-〉再总结
产品领域探讨(互联网领域)
该文主要探讨了如下一些问题：产品与业务的关系是什么；用事物本质来理解互联网产品；产品风格与产品品质是啥关系；产品服务质量和产品品质是啥关系；产品风格与用户需求；产品品质转换为产品需求；业务分析师的价值；产品风格与架构风格；产品分类和产品标识；产品与产品模型；产品与商品。该文也是希望抛个砖头，和大家一起探讨这些产品领域。详细请进。
构建架构的思考
（说明：以下内容仅仅是一种思考，而不是某家公司的具体内容，在此过程中，参考了多篇 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，总是尝试各类方法，不解决问题，决不罢休
- 不断总结-〉实践-〉再总结
