BlogJava-paulwong-随笔分类-SOFTWARE ARCHITECTURE

Enterprise Architect VS Solution Architect VS Software Architect

paulwong — Mon, 11 Oct 2021 07:29:00 GMT

Enterprise Architect
定义企业的大概方向

Solution Architect
定义系统使用哪些框架技术

Software Architect
定义系统行为

Technical Architect
定义有关部署所使用服务器

https://stackoverflow.com/questions/524941/whats-the-difference-between-solutions-architect-and-applications-architect

https://www.youtube.com/watch?v=zB9WuYE1REI

paulwong 2021-10-11 15:29 发表评论

怎么提高自己的系统架构水平

paulwong — Wed, 04 Aug 2021 03:05:00 GMT

https://my.oschina.net/u/4662964/blog/5135740

paulwong 2021-08-04 11:05 发表评论

!!!架构网站内容不错

paulwong — Tue, 19 Apr 2016 09:54:00 GMT

http://colobu.com/categories/%E6%9E%B6%E6%9E%84/page/2/

paulwong 2016-04-19 17:54 发表评论

应用系统架构

paulwong — Thu, 04 Dec 2014 14:15:00 GMT

做任何一个应用系统，比如银行核心、ERP核心、订票系统等等，应用系统都包括三个架构：1）业务架构；2）系统架构；3）实施架构。

1）业务架构
业务架构是应用系统的业务范围的具体划分和体现。业务架构与将要落地的系统平台无关。
业务架构的搭建，可以在概设阶段完成轮廓的搭建，对一些具体的细节，可以没有，或将会存在。但是，要在架构搭建过程中，把控着，或设计者，要留有充分的包容余地。

业务架构具体内容，要有粗细业务流的体现。每个业务流肯定要行得通。对综合或交叉的业务流要详细划分，按通用性，或者特殊性，划分为各自的子集。

业务架构要包括应用系统项目的当前实施范围，或将要实施的范围。

业务架构应该做到，业务范围内容的增加，不影响已经搭建好的业务架构，并且，比较容易地融合到业务架构中。

在业务架构搭建过程中，对熟悉的、惯例的业务用细业务流按模块划分，进行描述。对没有落地的业务内容，按粗业务流进行模块划分描述。划分好的业务功能模块，在业务架构中是唯一的，不能重叠。

2）系统架构
系统架构是业务架构落实到具体硬件平台的应用，硬件平台如HP-UX、RS6000、ES9000、AS400等等，操作系统如UNIX、AIX、390 Z系统、OS400、LINUX等等。

架构师的责任就是把业务架构的各个模块在一个单独硬件平台上，或一个整体，包括多个层次复杂的综合硬件系统平台上，把应用系统落实在最能体现硬件平台运行效率的地方。

业务架构是有范围的，在现有状况下，或将来一定时间段，实现的业务架构都会满足现有项目需求。

优秀的架构师，整体观要非常强，精通当今至少一条行业技术方向和主要技术，熟悉当今IT潮流硬件平台，和在此之下的潮流软件实施技术。

架构师不是万能的，但是，在架构师的统帅下，各分支的模块架构实现，要根据架构师规划和设计的系统架构轮廓进行实施，具体模块实现要team leader，根据模块特征，做具体技术设计和实现。

架构师职责之一，就是把控应用系统项目实施规范。

打个比方，IT架构师，就像建筑总体架构师，业务架构就像一个建筑架构，比如一个社区的建筑规划，哪里是居住区？哪里是电影院？哪里是超市？等等，这些都是在社区建设初期，架构师就要设计和规划出轮廓。对具体细节操作，比如社区中有一块区域要建筑一座楼房，第三层要实现中式复古装修；第四层要实现欧式宫廷式装修，等等，每一层都有各自熟悉精通这方面的team leader设计领导实施。

架构师的职责之一，就是会懂得用人，把各team leader放在最能发挥作用的地方。

一个好的应用系统，不会因为业务扩充或变化，而影响应用系统运行和运行效率。不提倡打补丁的做法。功能唯一，包括功能代码唯一，是好的系统架构的保障，同时也是评价一个优秀架构师的标准。

3）实施架构
实施架构是系统架构具体实现手段，是体系项目实施提升效率的具体实施行为。

paulwong 2014-12-04 22:15 发表评论

聊聊架构

paulwong — Fri, 28 Nov 2014 15:06:00 GMT

什么是系统架构？

从字面上理解，系统架构是系统的框架结构，是系统进行抽象之后的一个草图。它包含了系统中各个抽象组件的协作方式。

为什么需要架构？

好的架构能够降低系统的创造和维护成本，特别是维护成本。一个系统的创造成本低，而维护的成本大，特别是互联网应用，一般情况下把一个系统搞上线只需要一个月，但是有的系统搞下线缺需要几个月，而维护则需要数年。好的设计师不会在系统上线后对系统进行大的修改，从而减少系统的维护成本。

如果区分创造和维护两个阶段的话，架构师分为系统架构师和维护架构师，架构新的系统的是系统架构师，而维护老系统的则是维护架构师，程序员大多数愿意做新系统不愿意维护老系统，因为感觉没什么技术含量，但是维护老的系统反而更难，因为老系统的重构和改进更加复杂，维护架构师不仅需要读懂老系统架构设计，还要在不影响老系统功能的情况下，进行功能新增和重构。我的一位同事在对一个旧的系统进行重构之前，读了几个星期的代码，然后才开始设计改进方案。

架构设计的目标

设计的目标围绕着降低成本这个需求进行。设计的目标非常多，不同的系统架构目标也不一致，但是我觉得比较重要的架构目标有以下几个，可扩展性，灵活性和可插入性。

可扩展性，新的功能容易加入到系统里，降低创造成本。
灵活性，一处修改不会波及其他的地方，降低维护成本。
可插入性，同样的功能可方便的替换，降低创造和维护成本。
那么如何实现这三个目标

提高可扩展性：把不易变的抽象出来。抽象层要比实现层要更稳定，抽象层的变化要少。把变化的集中起来，比如把容易变化的功能放在单独一个系统或者一个模块里。
灵活性：模块化，每个模块相互独立，减少模块之间的藕合度，修改不会互相传递。
提高可插入性：模块化，服务化。
如何开始架构

当一块新业务放在你面前时，如何进行系统架构？我觉得需要进行以下几个步骤的思考：

业务分析：输出业务架构图，这个系统里有多少个业务模块，从前台用户到底层一共有多少层。
系统划分：根据业务架构图输出系统架构图，需要思考的是这块业务划分成多少个系统，可能一个系统能支持多个业务。基于什么原则将一个系统拆分成多个系统？又基于什么原则将两个系统合并成一个系统？
系统分层：系统是几层架构，基于什么原则将一个系统进行分层，分成多少层？
模块化：系统里有多少个模块，哪些需要模块化？基于什么原则将一类代码变成一个模块。

paulwong 2014-11-28 23:06 发表评论

软件架构师应具备的十大特点

paulwong — Wed, 05 Nov 2014 04:55:00 GMT

如果有人问你，作为一个软件架构师需要哪些特质的话，你会怎么回答？从技术层面上讲，架构师的技术要求是首位的。除此之外在做人处事方面，更有魅力的架构师则更受欢迎。
最近有个同事问我，是什么成就了一个架构师。下文就是我的回答，适用于各个技术领域。其中我故意不考虑企业架构相关的问题。

1、了解相关领域的技术知识

在你想要成为架构师的相关技术领域，必须具备扎实的专业知识和过人的本领。

2、超强的分析、设计能力

不管怎样，具备很强的分析和设计能力都是必杀技。另外就是能够运用设计模式方式解决各种各样的问题。

3、编码与验证性测试（POC）

熟悉该组织整个技术栈，并能使用各层的技术熟练地编码。
能快速实现验证性测试。

4、架构设计的实力

能为原始需求提供架构方案。
考虑周全：工具和框架的采用、安全性、性能和扩展性、依赖关系、集成、效益。
熟悉软件开发生命周期（SDLC）：需求、分析、设计、测试、打包、部署。

5、建模语言或工具

能使用不同的建模语言或工具，向其他架构师、开发者、项目经理等人，阐述架构。

6、架构框架

能证明架构的可行性，包括其业务、应用、数据、基础设置方面。
了解TOGAF和ZACHMAN框架就更好了。

7、沟通能力

能与开发人员、测试人员、商业分析师、上级经理沟通无阻，无论在口头上和书面上。

8、布道

能讲解该行业的市场、技术知识。
能为全队提供培训课程。

9、销售、甚至售前

能参与售前工作（尤其对于软件服务业）：制定技术方案、使用各种预算工具估计方案的规模和成本、与销售对象互动。

10、演讲技巧

优秀的演讲技巧，有助于以下活动：华丽的计划书和技术文档、PPT演讲、布道。

paulwong 2014-11-05 12:55 发表评论

架构师的职责

paulwong — Tue, 05 Aug 2014 10:35:00 GMT

近来看到CSDN上有个CTO俱乐部，里面聊得是不亦乐乎。我怀着无比崇敬的态度，拜读了一下牛人们的发言。

里面有个哥们发起一个话题：

“CTO, 你多久没有写程序了？”。
有人回答：“不写代码的CTO,属于......这公司问题大了!”。

看到这里，我就赶紧撤了，怕忍不住反驳几句，反而遭到牛人们的群殴。试想，一个上点规模的IT公司，还得靠CTO来写程序的话，那是不是才叫问题大了呢。当然，我没有做过CTO，所以我有我的不同看法，而且还愿意表达出来，无知者无畏。我情愿相信：我所理解的CTO跟这位CTO所理解的是两回事。所以我想，如果有人能把CTO的职责给标准化了，也许就不会有这么多的争论了。

同样的道理，关于架构师的定义，大家也有着不同的理解。什么是架构师？架构师有哪些职责？我觉得有必要提前明确一下，要不然大家沟通起来也会产生类似问题，子说子理，卯说卯理，但是压根说得不是一码子事。

0.1 什么是架构师

曾经有这么个段子：

甲：我已经应聘到一家中型软件公司了，今天上班的时候，全公司的人都来欢迎我。

乙：羡慕ing，都什么人来了？

甲：CEO、COO、CTO、All of 程序员，还有会计、司机都来了。

乙：哇，他们太重视你了，人才啊，这么多人迎接你！

甲：没有啊，就一个人！

乙：靠，#%￥$%...

很多的创业公司，一人身兼数职的情形还是很常见的。至少，我是经历过的，一个人包办了所有的开发过程，连测试我都做了，绝对的一条龙，但是经常踩钢丝、骑独轮车总会有失足的时候，结果有一次，从我手里发出去的光盘母盘，含有病毒僵尸，以至于被迫收回已经推上市场的2万张光盘，从那之后，我的心脏就开始变得无比坚强，现在就是整个后台服务都瘫痪了，我也只是微微一笑。其实，一个人身兼架构师和程序员，甚至多种角色，没什么不妥，后面还会讲这个话题，这种现象不是中国特色，跟国外是完全接轨的。我曾经跟米国的一个工程师在msn中聊过类似的话题，发现他们的路子跟咱们没什么不同，在IT这个行业，我们跟世界的差距只有1天，他们刚弄出来的新东西，我们这里第2天保准见得到。

架构师这个称呼不是拍脑袋想出来的，是有国际标准（ISO/IEC 42010）可查的。架构师是软件开发活动中的众多角色之一，它可能是一个人、一个小组，也可能是一个团队。微软对架构师有一个分类参考，我们参考一下，他们把架构师分为4种：企业架构师EA(Enterprise Architect)、基础结构架构师IA(Infrastructure Architect)、特定技术架构TSA(Technology-Specific Architect)和解决方案架构师SA (Solution Architect)。微软的这个分类是按照架构师专注的领域不同而划分的。

EA的职责是决定整个公司的技术路线和技术发展方向。盖茨给自己的Title就是首席软件架构师，网易丁磊也喜欢这么称呼自己，实际上就是EA角色；IA的工作就是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架和组件，这些都是一个技术型公司传承下来的最宝贵的财富之一；特定技术架构师TSA，他们主要从事类似安全架构、存储架构等专项技术的规划和设计工作；SA的工作则专于解决方案的规划和设计，“解决方案”这个词在中国已经到了严重泛滥的程度，大忽悠们最喜欢把它挂在嘴边。所谓解决方案，就是把产品、技术或理论，不断地进行组合，来创造出满足用户需求的选择。售前工程师一般都是带着它到客户那里去发挥的。

大公司会把各种类型的架构师分得很清楚，小公司一般就不那么讲究了，架构师多数是是IA+TSA+SA，一人包打天下，所以说大公司出专才，小公司出全才。

实际工作中，我们也经常会见到另一种比较简单的分类方式，把架构师分为软件架构师和系统架构师。软件架构师基本上是TSA+IA，这也是程序员最容易突破，最可能走上的一条道路，比如JAVA架构师、DotNet架构师、LAPM架构师等等，我后面所讲的内容都是与软件架构师的相关的话题。系统架构师实际上是SA+TSA，更着力于综合运用已有的产品和技术，来实现客户期望的需求。系统架构师要求通晓软、硬件两方面的知识，所以它的知识体系相对庞杂。关于系统架构师的话题，我们可以稍后再作讨论。

0.2 架构师的职责

架构师需要参与项目开发的全部过程，包括需求分析、架构设计、系统实现、集成、测试和部署各个阶段，负责在整个项目中对技术活动和技术说明进行指导和协调。

架构师主要职责有4条：

1、确认需求

在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。

2、系统分解

依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。

软件架构师的功力基本体现于此，这是一项相对复杂的工作。

3、技术选型

架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。

Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。

架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。

4、制定技术规格说明

架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。

架构师与开发者沟通的最重要的形式是技术规格说明书，它可以是UML视图、Word文档，Visio文件等各种表现形式。通过架构师提供的技术规格说明书，保证开发者可以从不同角度去观察、理解各自承担的子系统或者模块。

架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。

0.3 架构师的误区

1、架构师就是项目经理

架构师不是项目经理。项目经理侧重于预算控制、时间进度控制、人员管理、与外部联系和协调等等工作，具备管理职能。一般小型项目中，常见项目经理兼架构师。

2、架构师负责需求分析

架构师不是需求分析员。需求分析人员的工作是收集需求和分析需求，并与最终用户、产品经理保持联系。架构师只对最终的需求审核和确认，提出需求不清和不完整的部分，他会跟需求分析员时刻保持联系。架构师是技术专家，不是业务专家。

3、架构师从来不写代码

这是一个尚存争论的问题。目前有两种观点：

观点1：架构师不写代码，写代码纯体力活，架构师写代码大材小用。架构师把UML的各种视图交给开发人员，如果有不明确的地方，可以与架构师随时沟通。

观点2：架构师本来自于程序员，只是比程序员站的层面更高，比程序员唯一多的是经验和知识，所以架构师也免不了写代码。

我个人觉得这两种说法是与架构师的出身和所处的环境有关。

架构师首先是一个技术角色，所以一定是来自于技术人员这个群体，比如系统架构师，多是来自于运维人员，可能本身代码写得并不多，或者说写不出来很漂亮的代码。软件架构师多是来自于程序员，有着程序员的血统和情怀，所以在项目开发过程中，可能会写一些核心代码。我们的理想是架构师不用写代码，但事实上有时候过于理想。架构师写不写代码，可能取决于公司的规模、文化、开发人员的素质等现实情况。另外，架构师也不是跟程序员界限分得那么清楚，按照能力也有高中低之分，写不写代码不是区分两者的根本标准。

0.4 架构师的基本素质

周星驰有个片子《喜剧之王》，剧中的尹天仇整天揣着本《演员的自我修养》，一个好演员不仅需要天赋，也需要一定的理论指导，无师自通的人毕竟是少数。架构师的成长过程也是这样。从普通程序员到高级程序员，再到架构师，是一个经验积累和思想升华的过程。经验积累是一个方面，素质培养是另一个方面，两者相辅相成，所以我觉得有必要把架构师的所要具备的素质罗列一下，作为程序员努力的方向。

1、沟通能力

为了提高效率，架构师必须赢得团队成员、项目经理、客户或用户认同，这就需要架构师具有较强的沟通能力。沟通能力是人类最普遍性的素质要求，技术人员好像容易忽略，想成为架构师就不能忽略。千万不要抱着这样的观念：怀才跟怀孕似的，时间久了总会被人发现的。还是天桥上卖大力丸的哥们说得对：光说不练假把式，光练不说傻把式。看看你周围的头头脑脑们，哪一个不是此中高手，我们千万不要鄙视，认为这是阿谀奉承、投机钻营，凡事都要看到积极的一面，“沟通”的确是一种能力。我认为自己是一个略内向的人，因为我是农村出来的孩子，普通话都说不好，以前或多或少带有点自卑感，幻想着是金子总会发光，所以在职业生涯中吃了不少亏。现在，我深深懂得了沟通的重要性，我会很主动地跟同事们，跟老大们不定时地沟通，感觉工作起来顺畅多了。

这一条我认为最为重要，所以排在首位。我甚至认为下面几条都可以忽略，唯一这一条得牢记，而且要常常提醒自己。

2、领导能力

架构师能够推动整个团队的技术进展，能在压力下作出关键性的决策，并将其贯彻到底。架构师如何来保证这种执行力？这就需要架构师具有领导能力。

架构师的领导能力的取得跟项目经理不太一样。项目经理主要负责解决行政管理，这种能力与技术关系不大，他有人权和财权，再扯上一张“领导”的虎皮，采用“胡萝卜加大棒”的方式，基本上可以保证执行力。架构师在项目里面可能更多地使用非正式的领导力，也就是我们常说的影响力，里面包括个人魅力、技术能力、知识传递等等。

3、抽象思维和分析能力

架构师必须具备抽象思维和分析的能力，这是你进行系统分析和系统分解的基本素质。只有具备这样的能力，架构师才能看清系统的整体，掌控全局，这也是架构师大局观的形成基础。你如何具备这种能力呢？一是来自于经验，二是来自于学习。架构师不仅要具备在问题领域上的经验，也需要具备在软件工程领域内的经验。也就是说，架构师必须能够准确得理解需求，然后用软件工程的思想，把需求转化和分解成可用计算机语言实现的程度。经验的积累是需要一个时间过程的，这个过程谁也帮不了你，是需要你去经历的。但是，如果你有意识地去培养，不断吸取前人的经验的话，还是可以缩短这个周期的。这也是我写作此系列的始动力之一。

4、技术深度和广度

架构师最好精通1-2个技术，具备这种技术能力可以更加深入的理解有关架构的工作原理，也可以拉近和开发人员的距离，并形成团队中的影响力。

架构师的技术知识广度也很重要，需要了解尽可能多的技术，所谓见多识广，只有这样，才可能综合各种技术，选择更加适合项目的解决方案。有的人说，架构师技术广度的要求高于技术深度的要求，这是很有道理的。

总而言之，一句话：架构师是项目团队中的技术权威。

paulwong 2014-08-05 18:35 发表评论

三层架构及其优缺点

paulwong — Wed, 09 Jul 2014 09:24:00 GMT

三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为：表现层（UI）、业务逻辑层（BLL）、数据访问层（DAL）。区分层次的目的即为了“高内聚，低耦合"的思想。
　　１、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。
　　２、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。
　　３、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。
注：（内聚：一个模块内各个元素彼此结合的紧密程度；耦合：一个软件结构内不同模块之间互连程度的度量）

优缺点
　　优点：
　　1、开发人员可以只关注整个结构中的其中某一层；
　　2、可以很容易的用新的实现来替换原有层次的实现；
　　3、可以降低层与层之间的依赖；
　　4、有利于标准化；
　　5、利于各层逻辑的复用。
6、扩展性强。不同层负责不同的层面，如PetShop可经过简单的配置实现Sqlserver和oracle之间的转换，当然写好了也可以实现B/S与C/S之间的转换
7、安全性高。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。
8、项目结构更清楚，分工更明确，有利于后期的维护和升级

　　缺点：
　　1、降低了系统的性能。这是不言而喻的。如果不采用分层式结构，很多业务可以直接造访数据库，以此获取相应的数据，如今却必须通过中间层来完成。
　　2、有时会导致级联的修改。这种修改尤其体现在自上而下的方向。如果在表示层中需要增加一个功能，为保证其设计符合分层式结构，可能需要在相应的业务逻辑层和数据访问层中都增加相应的代码
3、增加了代码量，增加了工作量

三层架构是：

一：界面层
界面层提供给用户一个视觉上的界面，通过界面层，用户输入数据、获取数据。界面层同时也提供一定的安全性，确保用户不用看到不必要的机密信息。

二：逻辑层

逻辑层是界面层和数据层的桥梁，它响应界面层的用户请求，执行任务并从数据层抓取数据，并将必要的数据传送给界面层。

三：数据层
数据层定义、维护数据的完整性、安全性，它响应逻辑层的请求，访问数据。这一层通常由大型的数据库服务器实现，如Oracle 、Sybase、MS SQl Server等。

------

从开发角度和应用角度来看，三层架构比双层或单层结构都有更大的优势。三层结构适合群体开发，每人可以有不同的分工，协同工作使效率倍增。开发双层或单层应用时，每个开发人员都应对系统有较深的理解，能力要求很高，开发三层应用时，则可以结合多方面的人才，只需少数人对系统全面了解，从一定程度工降低了开发的难度。
三层架构属于瘦客户的模式，用户端只需一个较小的硬盘、较小的内存、较慢的CPU就可以获得不错的性能。相比之下，单层或胖客户对面器的要求太高。
三层架构的另一个优点在于可以更好的支持分布式计算环境。逻辑层的应用程序可以有多个机器上运行，充分利用网络的计算功能。分布式计算的潜力巨大，远比升级CPU有效。
三层架构的最大优点是它的安全性。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了。
另外三层架构还可以支持如下功能：Remote Access(远程访问资料)，例如可透过Internet存取远程数据库；High Performance(提升运算效率)解决集中式运算(Centralize)及主从式架构(Client-Server)中，数据库主机的运算负担，降低数据库主机的Connection Load，并可藉由增加App Server处理众多的数据处理要求，这一点跟前面讲到的分布式计算提高运算能力是一个道理；Client端发出Request(工作要求)后，便可离线，交由App Server和DataBase Server共同把工作完成，减少Client端的等待时间；这个功能我觉得应用场合不是很多，自己感受也不是很深刻，从理论上是成立的。

paulwong 2014-07-09 17:24 发表评论

转（探讨分布式系统与集群的区别）

paulwong — Fri, 23 May 2014 05:27:00 GMT

简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。

　　例如：如果一个任务由10个子任务组成，每个子任务单独执行需1小时，则在一台服务器上执行改任务需10小时。

　　采用分布式方案，提供10台服务器，每台服务器只负责处理一个子任务，不考虑子任务间的依赖关系，执行完这个任务只需一个小时。

　　而采用集群方案，同样提供10台服务器，每台服务器都能独立处理这个任务。假设有10个任务同时到达，10个服务器将同时工作，10小后，10个任务同时完成，这样，整身来看，还是1小时内完成一个任务!

　　集群概念

　　1. 两大关键特性

　　集群是一组协同工作的服务实体，用以提供比单一服务实体更具扩展性与可用性的服务平台。在客户端看来，一个集群就象是一个服务实体，但事实上集群由一组服务实体组成。与单一服务实体相比较，集群提供了以下两个关键特性：

　　· 可扩展性--集群的性能不限于单一的服务实体，新的服务实体可以动态地加入到集群，从而增强集群的性能。

　　· 高可用性--集群通过服务实体冗余使客户端免于轻易遇到out of service的警告。在集群中，同样的服务可以由多个服务实体提供。如果一个服务实体失败了，另一个服务实体会接管失败的服务实体。集群提供的从一个出错的服务实体恢复到另一个服务实体的功能增强了应用的可用性。

　　2. 两大能力

　　为了具有可扩展性和高可用性特点，集群的必须具备以下两大能力：

　　· 负载均衡--负载均衡能把任务比较均衡地分布到集群环境下的计算和网络资源。

　　· 错误恢复--由于某种原因，执行某个任务的资源出现故障，另一服务实体中执行同一任务的资源接着完成任务。这种由于一个实体中的资源不能工作，另一个实体中的资源透明的继续完成任务的过程叫错误恢复。

　　负载均衡和错误恢复都要求各服务实体中有执行同一任务的资源存在，而且对于同一任务的各个资源来说，执行任务所需的信息视图(信息上下文)必须是一样的。

　　3. 两大技术

　　实现集群务必要有以下两大技术：

　　· 集群地址--集群由多个服务实体组成，集群客户端通过访问集群的集群地址获取集群内部各服务实体的功能。具有单一集群地址(也叫单一影像)是集群的一个基本特征。维护集群地址的设置被称为负载均衡器。负载均衡器内部负责管理各个服务实体的加入和退出，外部负责集群地址向内部服务实体地址的转换。有的负载均衡器实现真正的负载均衡算法，有的只支持任务的转换。只实现任务转换的负载均衡器适用于支持ACTIVE-STANDBY的集群环境，在那里，集群中只有一个服务实体工作，当正在工作的服务实体发生故障时，负载均衡器把后来的任务转向另外一个服务实体。

　　· 内部通信--为了能协同工作、实现负载均衡和错误恢复，集群各实体间必须时常通信，比如负载均衡器对服务实体心跳测试信息、服务实体间任务执行上下文信息的通信。

　　具有同一个集群地址使得客户端能访问集群提供的计算服务，一个集群地址下隐藏了各个服务实体的内部地址，使得客户要求的计算服务能在各个服务实体之间分布。内部通信是集群能正常运转的基础，它使得集群具有均衡负载和错误恢复的能力。

　　集群分类

　　Linux集群主要分成三大类( 高可用集群，负载均衡集群，科学计算集群)，高可用集群( High Availability Cluster)，负载均衡集群(Load Balance Cluster)，科学计算集群(High Performance Computing Cluster)

　　具体包括：

　　Linux High Availability 高可用集群：普通两节点双机热备，多节点HA集群，RAC, shared, share-nothing集群等；Linux Load Balance 负载均衡集群：LVS等....；Linux High Performance Computing 高性能科学计算集群：Beowulf 类集群....；分布式存储；其他类linux集群：如Openmosix, rendering farm 等..

　　详细介绍

　　1. 高可用集群(High Availability Cluster)

　　常见的就是2个节点做成的HA集群，有很多通俗的不科学的名称，比如"双机热备", "双机互备", "双机".

　　高可用集群解决的是保障用户的应用程序持续对外提供服务的能力。 (请注意高可用集群既不是用来保护业务数据的，保护的是用户的业务程序对外不间断提供服务，把因软件/硬件/人为造成的故障对业务的影响降低到最小程度)。

　　2. 负载均衡集群(Load Balance Cluster)

　　负载均衡系统：集群中所有的节点都处于活动状态，它们分摊系统的工作负载。一般Web服务器集群、数据库集群和应用服务器集群都属于这种类型。

　　负载均衡集群一般用于相应网络请求的网页服务器，数据库服务器。这种集群可以在接到请求时，检查接受请求较少，不繁忙的服务器，并把请求转到这些服务器上。从检查其他服务器状态这一点上看，负载均衡和容错集群很接近，不同之处是数量上更多。

　　3. 科学计算集群(High Performance Computing Cluster)

　　高性能计算(High Perfermance Computing)集群，简称HPC集群。这类集群致力于提供单个计算机所不能提供的强大的计算能力。

　　高性能计算分类

　　高吞吐计算(High-throughput Computing)

　　有一类高性能计算，可以把它分成若干可以并行的子任务，而且各个子任务彼此间没有什么关联。象在家搜寻外星人( SETI@HOME -- Search for Extraterrestrial Intelligence at Home )就是这一类型应用。这一项目是利用Internet上的闲置的计算资源来搜寻外星人。SETI项目的服务器将一组数据和数据模式发给Internet上参加SETI的计算节点，计算节点在给定的数据上用给定的模式进行搜索，然后将搜索的结果发给服务器。服务器负责将从各个计算节点返回的数据汇集成完整的数据。因为这种类型应用的一个共同特征是在海量数据上搜索某些模式，所以把这类计算称为高吞吐计算。所谓的Internet计算都属于这一类。按照 Flynn的分类，高吞吐计算属于SIMD(Single Instruction/Multiple Data)的范畴。

　　分布计算(Distributed Computing)

　　另一类计算刚好和高吞吐计算相反，它们虽然可以给分成若干并行的子任务，但是子任务间联系很紧密，需要大量的数据交换。按照Flynn的分类，分布式的高性能计算属于MIMD(Multiple Instruction/Multiple Data)的范畴。

　　4. 分布式(集群)与集群的联系与区别

　　分布式是指将不同的业务分布在不同的地方。而集群指的是将几台服务器集中在一起，实现同一业务。分布式中的每一个节点，都可以做集群。而集群并不一定就是分布式的。

　　举例：就比如新浪网，访问的人多了，他可以做一个群集，前面放一个响应服务器，后面几台服务器完成同一业务，如果有业务访问的时候，响应服务器看哪台服务器的负载不是很重，就将给哪一台去完成。

　　而分布式，从窄意上理解，也跟集群差不多，但是它的组织比较松散，不像集群，有一个组织性，一台服务器垮了，其它的服务器可以顶上来。

　　分布式的每一个节点，都完成不同的业务，一个节点垮了，哪这个业务就不可访问了。

paulwong 2014-05-23 13:27 发表评论

超大型电商系统架构解密

paulwong — Fri, 17 Jan 2014 04:00:00 GMT

http://www.infoq.com/cn/presentations/decrypt-the-architecture-of-large-e-commerce-system?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

paulwong 2014-01-17 12:00 发表评论

大型网站技术架构读书笔记

paulwong — Sat, 09 Nov 2013 03:34:00 GMT

大型网站经历的技术架构演变：

应用服务器、数据库服务器和文件服务器都安装在同一台主机
应用服务器、数据库服务器和文件服务器分别安装在不同主机
增加了分布式的缓存服务器
应用服务器增加了好几台，变成集群
增加了CDN和反射代理服务器
数据库服务器变成主从形式的服务器
数据库服务器变成分布式的服务器，文件服务器也变成分布式服务器
NOSQL分布式数据库和搜索引擎的引入
应用服务器虽然是多台，但都是部署了同一应用，这时将应用拆分，每台服务器部署不同的拆分应用
虽然应用已经拆分，但每个应用都是从页面管到数据库，这时继续拆分，将存取数据库的部份独立，页面部份
也独立

架构模式

分层，代码放在不同的类中
分割，应用放在不同的JVM中
分布式，部署在不同的物理机
集群，同一个应用部署到不同的主机，可以负载均衡
缓存，CND加速、反向代理、本地缓存、分布式缓存
异步，消除高并发
冗余，多处备份
安全性

paulwong 2013-11-09 11:34 发表评论

architecture requirement

paulwong — Tue, 25 Jun 2013 01:03:00 GMT

Responsibilities:

• Provide high level technical architecture, design documents and build of business applications and supporting functions based upon customer’s requirements.

• Produce a detailed functional design document to match customer requirements

• Co-operate with the customer’s technical architect to produce a technical specification for custom development and systems integration requirements.

• Ensure delivered solutions are realized in time frame committed

• Participate and lead the project meetings and present the solution with the customer if needed

• Review the work of other team members and ensure it meets the required standards

• Work with team members of the team to improve their technical and functional knowledge and skills.

• Act as a mentor to all team members on their assigned project tasks.

• Drive new business growth and customer success by providing business expertise.

Required Qualifications:

• Graduated from University or equivalent.

• 5-7+ years of relevant experience in software development.

• Must have hands-on expertise in the following technologies: Java/J2EE, Spring framework, Hibernate, Web Service (SOAP and RESTful), database (Oracle, SQL, PL/SQL, stored procedures)

• Have good knowledge in web-based systems architecture, service-based architecture, enterprise application architecture.

• Ability to understand the business requirements and converting them into solution designs

• Have excellent English written and oral communication skills, including conducting presentations to customers.

paulwong 2013-06-25 09:03 发表评论

Architecture Representation

paulwong — Tue, 21 May 2013 03:02:00 GMT

The architecture representation will basically adopt the 4 + 1 View Model as

recommended, to organize the architectural description from different perspectives, each

of which addresses a specific set of concerns:

• Requirement View – describes the software requirements, functional and

non-functional, illustrated by significant use cases and scenarios.

• Logical View – describes the object model of the design, the system

decomposition into layers and subsystems, and the dependencies between them.

• Process View – describes the concurrency and synchronization aspects of the

design.

• Implementation View – describes the software’s static organization in the

development environment.

• Deployment View – describes the mapping of the software onto hardware.

• Data View – describes the database design for the software.

It allows various stakeholders to find what they need in the software architecture. System

engineers can approach it from the logical view, process view and deployment view. DBA

can approach it from the data view. Project managers and software configuration

managers can approach it from the development view.

Demo:

CUHK RFID - White Paper

Middleware Quick Start Guide

Tag Capturer Quick Start Guide

Middleware System Design Document

Tag Capturer System Design Document

Middleware Test Cases

Middleware Test Plan

Middleware Source Code

paulwong 2013-05-21 11:02 发表评论

企业信息管理系统 JeeSite

paulwong — Sun, 24 Feb 2013 08:45:00 GMT

JeeSite是一个 开源的企业信息管理系统 基础框架。主要定位于“企业信息管理”领域，可用作企业信息管理类系统、网站后台管理类系统等。JeeSite是非常强调开发的高效性、健壮性和安全性的。

JeeSite是轻量级的，简单易学，本框架以Spring Framework为核心、Spring MVC作为模型视图控制器、Spring Data JPA + Hibernate作为数据库操作层，此组合是Java界业内最经典、最优的搭配组合。前端界面风格采用了结构简单、性能优良、页面精致的Twitter Bootstrap作为前端展示框架。

JeeSite 已内置 一系列企业信息管理系统的基础功能，目前包括两大模块，系统管理（SYS）模块和内容管理（CMS）模块。系统管理模块，包括企业组织架构（用户管理、部门管理、区域管理）、菜单管理、角色权限管理、字典管理等功能；内容管理模块，包括内容管理（文章、链接），栏目管理、站点管理、公共留言、文件管理、前端网站展示等功能。

JeeSite提供了常用工具进行封装，包括日志工具、缓存工具、服务器端验证、数据字典、当前组织机构数据（用户、区域、部门）以及其它常用小工具等。另外还提供一个基于本基础框架的 代码生成器 ，为你生成基本模块代码，如果你使用了JeeSite基础框架，就可以很快速开发出优秀的信息管理系统。

为何选择

使用 Apache License 2.0 协议，源代码完全开源，无商业限制。
使用目前最主流的J2EE开发框架，简单易学，学习成本低。
数据库无限制，支持MySql、Oracle、SQL Server、H2等数据库。
模块化设计，层次结构清晰。内置一系列企业信息管理的基础功能。
权限控制精密细致，对所有管理链接都进行权限验证，可控制到按钮。
提供基本功能模块的源代码生成器，提高开发效率及质量。
提供常用工具类封装，日志、缓存、验证、字典、组织机构等，常用标签（taglib），获取当前组织机构、字典等数据。
完全兼容目前最流行浏览器（IE6、IE7+、Firefox、Chrome）。

使用技术

1、Services相关

Core Framework：Spring Framework 3.1。
Security Framework：Apache Shiro 1.2。

2、Web相关

MVC Framework：SpringMVC 3.1。
Layout Decoration：SiteMesh 2.4。
JavaScript Library：JQuery 1.7。
CSS Framework：Twitter Bootstrap 2.0.4。
JavaScript/CSS Compressor：YUI Compressor 2.4。
Front Validation：JQuery Validation Plugin 1.9。

3、Database相关

ORM Framework：Spring-Data-JPA 1.2、Hibernate 4.1。
Connection Pool：BoneCP 0.7
Bean Validation：Hibernate Validation 4.3.0。
Cache：Ehcache 2.6。

4、Tools 相关

Commons：Apache Commons
JSON Mapper：Jackson 2.1
Bean Mapper：Dozer 5.3.2
Full-text search：Hibernate Search 4.2（Apache Lucene 3.6）、IK Analyzer 2012_u6中文分词
Log Manager：Log4j 1.2

安全考虑

开发语言：系统采用Java 语言开发，具有卓越的通用性、高效性、平台移植性和安全性。
分层设计：（数据库层，数据访问层，业务逻辑层，展示层）层次清楚，低耦合，各层必须通过接口才能接入并进行参数校验（如：在展示层不可直接操作数据库），保证数据操作的安全。
双重验证：用户表单提交双验证：包括服务器端验证及客户端验证，防止用户通过浏览器恶意修改（如不可写文本域、隐藏变量篡改、上传非法文件等），跳过客户端验证操作数据库。
安全编码：用户表单提交所有数据，在服务器端都进行安全编码，防止用户提交非法脚本及SQL注入获取敏感数据等，确保数据安全。
密码加密：登录用户密码进行SHA1散列加密，此加密方法是不可逆的。保证密文泄露后的安全问题。
强制访问：系统对所有管理端链接都进行用户身份权限验证，防止用户

快速体验

具备运行环境：JDK1.6、Maven3.0、MySql。
修改src\main\resources\application.properties文件中的数据库设置参数。
根据修改参数创建对应MySql数据库。
运行bin\resresh-db\refresh-db.bat脚本，导入表结构及演示数据
运行bin\jetty.bat，启动服务器（第一次运行，需要下载依赖jar包，请耐心等待）。
最高管理员，用户名：thinkgem 密码：admin

http://thinkgem.github.com/jeesite/

paulwong 2013-02-24 16:45 发表评论

架构的性能要求

paulwong — Thu, 30 Aug 2012 13:26:00 GMT

、性能要求：
Ø 支持同时在线用户量（访问网站页面）：10000人以上；
Ø 支持并发量：5000；
Ø 高峰负载时的平均响应时间（指每秒并发访问在4000以上）：
u 页面访问时间（用户实测）：1-5秒；
u 运行操作类响应时间（用户实测，50000个用户量）：1秒-10秒。
Ø 日常运行时的平均响应时间：
u 页面访问时间（用户实测）：1-3秒；
u 运行操作类响应时间（用户实测，100000个用户量）：1秒-6秒。
Ø 有效运行时间：
u 7x24小时：99%；
u 每年因系统本身问题导致的宕机次数：≤4；
u 因系统本身问题出现故障时的恢复时间：≤24小时。

这种要求有人能做得到吗？

paulwong 2012-08-30 21:26 发表评论

基于Java技术的大型网站架构方案(转)

paulwong — Tue, 21 Aug 2012 14:20:00 GMT

1、Web层
主体架构可以基于 Struts 1.X/2.X，当然有很多更好的控制层框架供选择，以快速敏捷为准则吧。
抽象出核心库封装控制器和中间层的操作。
在大规模集群环境下，session复制会引起严重的性能问题。考虑用集群缓存 + cookie验证代替session实现权限控制吧。

2、Cache层
配置 Memcache 组成集群缓存
对 Memcache 客户端进行封装
Memcached 节点组成池，调用示意：opList (BizName, 策略 ...)

3、中间层
“中间层”可以理解为基于应用和数据之间的层次。它被设计用来为Web应用提供：数据缓存和对应用透明的数据访问——即应用不需要考虑数据表拆分的问题。以服务的方式提供对存储层的高性能调用以及分布式计算。可供选择的框架：ICE 、Hadoop 直接基于Memcache开发（减少复杂度，推荐）

4、存储
推荐MySQL，理由：免费，经过实践检验，有大量成熟的案例、解决方案、技术支持。
小规模：一个 data table 维护存储服务器阵列，内容 -> mount ……
大规模：Master-Slave模式+MySQL Proxy，实现数据库读写分离。在中间层的包装下，可做如下扩展，以支持更大规模的数据存取：
数据库/表水平拆分，例 User -> User33% + User33% + User34%
数据库/表垂直拆分，例 User -> UserBaseInfo + UserAddrInfo
也可考虑使用 LongStore (龙存) 解决方案，由龙存管理存储阵列……

5、部署
划分子域名，每个子域名一个Web应用包，互不干扰
静态资源（css, js, image ...）使用专门的静态服务器

6、负载均衡
小规模：DNS轮询。
大规模：F5， 2*X 台F5服务器，F5是L4/L7层交换机，每台至少可处理200万连接（与服务器内存有关）。
Ngnix是L7层交换，LVS负载均衡也是一种方案

7、Web中间件选择
Tomcat - 最高400并发
Apache - 最高2000并发
Ngnix - 优于Apache
采用方案：Ngnix + Resin ，理由：
Resin提供更为快速的servlet引擎 - 选择Resin。
gzip问题 - Resin在单独处理gzip时存在内存溢出的隐患，因此要加一层 Ngnix。
Ngnix 能减少单独使用Resin时的内存占用 - Resin建立1000个连接使用1000个线程；加Ngnix后，透过其“异步连接”、“建立长连接”机制使Resin内存压力大大减小。
Ngnix 针对Linux系统有性能优化措施 - 0 Copy, send file ...
因此采用：1 Ngnix + 1 Resin，一对一。
静态服务器采用：Squid + Apache, why? because Squid has cache ability ...
新变化 - Nginx从0.7.48版本开始，支持了类似Squid的缓存功能。这个缓存是把URL及相关组合当作Key，用md5编码哈希后保存在硬盘上，所以它可以支持任意URL链接，同时也支持 404/301/302 这样的非200状态码。虽然目前官方的Nginx Web缓存服务只能为指定URL或状态码设置过期时间，不支持类似Squid的PURGE指令，手动清除指定缓存页面，但是，通过一个第三方的Nginx模块，可以清除指定URL的缓存。
Nginx的Web缓存服务主要由proxy_cache相关指令集和fastcgi_cache相关指令集构成，前者用于反向代理时，对后端内容源服务器进行缓存，后者主要用于对FastCGI的动态程序进行缓存。两者的功能基本上一样。
最新的Nginx 0.8.31版本，proxy_cache和fastcgi_cache已经比较完善，加上第三方的ngx_cache_purge模块（用于清除指定URL的缓存），已经可以完全取代Squid。有的网站已经在生产环境使用了 Nginx 的 proxy_cache 缓存功能超过两个月，十分稳定，速度不逊于 Squid。
在功能上，Nginx已经具备Squid所拥有的Web缓存加速功能、清除指定URL缓存的功能。而在性能上，Nginx对多核CPU的利用，胜过Squid不少。另外，在反向代理、负载均衡、健康检查、后端服务器故障转移、Rewrite重写、易用性上，Nginx也比Squid强大得多。这使得一台Nginx可以同时作为"负载均衡服务器"与"Web缓存服务器"来使用。以下是配置片段供参考：
view plaincopy to clipboardprint?
http
{
   ...
   client_body_buffer_size 512k;
   proxy_connect_timeout    5;
   proxy_read_timeout       60;
   proxy_send_timeout       5;
   proxy_buffer_size        16k;
   proxy_buffers            4 64k;
   proxy_busy_buffers_size 128k;
   proxy_temp_file_write_size 128k;
   ...
   #注：proxy_temp_path和proxy_cache_path指定的路径必须在同一分区
   proxy_temp_path   /data0/proxy_temp_dir;
   #设置Web缓存区名称为cache_one，内存缓存空间大小为200MB，1天清理一次缓存，硬盘缓存空间大小为30GB。
   proxy_cache_path /data0/proxy_cache_dir levels=1:2   keys_zone=cache_one:200m inactive=1d max_size=30g;
}
server
{
   ...
   location /
   {
     #如果后端的服务器返回502、504、执行超时等错误，自动将请求转发到upstream负载均衡池中的另一台服务器，实现故障转移。
     proxy_next_upstream http_502 http_504 error timeout invalid_header;
     proxy_cache cache_one;
     #对不同的HTTP状态码设置不同的缓存时间
     proxy_cache_valid 200 304 12h;
     proxy_cache_valid 301 302 1h;
     #以域名、URI、参数组合成Web缓存的Key值，Nginx根据Key值哈希，存储缓存内容到二级缓存目录内
     proxy_cache_key $host$uri$is_args$args;
     proxy_set_header Host $host;
     proxy_set_header X-Forwarded-For $remote_addr;
     proxy_pass http://backend_server;
     expires      1d;
   }
   #用于清除缓存，假设一个URL为http://192.168.1.44/test.txt，通过访问http://192.168.4.44/purge/test.txt就可以清除该URL的缓存。
   location ~ /purge(/.*)
   {
     #设置只允许指定的IP或IP段才可以清除URL缓存。
     allow            127.0.0.1;
     allow            192.168.0.0/16;
     deny            all;
     proxy_cache_purge    cache_one   $host$1$is_args$args;
   }
   #扩展名以.php、.jsp、.cgi结尾的动态应用程序不缓存。
   location ~ .*\.(php|jsp|cgi)?$
   {
     proxy_set_header Host $host;
     proxy_set_header X-Forwarded-For $remote_addr;
     proxy_pass http://backend_server;
   }
}
同时，对于影响页面展现的静态资源，例如：css, js 等可以放在具有优质带宽的IDC（IDC=互联网数据中心，优质/高速的带宽也比较贵，正所谓一份价钱一分货）；其他的静态资源，如图片等可以放在价格相对低廉的IDC中，以域名区分两种静态资源，节省每一分钱。

8、网络拓扑图
          / Ngnix - 1:1 - Resin
F5 --
          \ Squid - 1:n - Apache

9、监控统计平台
业务统计 - 用户访问统计
软件性能 - 应用系统监控，例如：请求响应时间……
硬件/网络性能 - Ganglia监控

10、其它要点
IE浏览器对同一域名（包括子域名）只能建立2个连接，连接多了只能排队……
双F5架构，两台职能划分不同，镜像，心跳接管……
Raid存储阵列……
Linux操作系统及其优化……

paulwong 2012-08-21 22:20 发表评论

读书笔记-架构2

paulwong — Mon, 23 Jul 2012 09:58:00 GMT

改善非功能需求的最佳实践

冗余
负载均衡
方式有网络切换、集群管理、基于DNS配置的切换
算法有随机算法、选择响应时间最快的算法、选择负载最轻的算法、重型算法
失败转移

集群
将服务器组成一组，来统一进行管理，检测软、硬件的失败，处理系统的失败转移，自动因失败事件而重启

集群配置方式
两节点集群、集群对、Ring、N+1、N to N

改善性能
性能有两个关键点：
处理时间，从计算、数据调度、缓存和网络传输
阻塞时间，来源于资源竞争和另一流程的依赖

处理措施
使用好的算法或适用的技术
引入并行计算、限制并发请求以避免系统过度使用、TIME OUT措施

高可用
可用是指随时才能访问，不能访问的原因是硬件、网络、服务器软件、和应用组件的失败；
如果一个应用组件不能提供足够快的响应时间也是指不可用了，这是指系统正常运行情况下，由于正在同时处理很多任务而导致的延时。

改善措施
集群中的复制，有活跃式的复制：发给所有节点，节点都同时进行运算，但只采用其中一个作为响应；被动式的复制，只有主节点响应请求，其他节点与主节点同步。

扩展性改善
扩展的原因通常是因为需求的变更。最重要的目标是改善系统开发以适应快速的变化。

可采取的方法有：
定义清晰的范围、预知可能的变更（如果界面技术，隔离这一区域使其不能波及到其他地方）、使用高质量的对象模型（使用MVC模式来解耦界面组件和业务组件）

伸缩性的改善
垂直伸缩：增加处理器或内存等，对系统是透明的；
水平伸缩：增加服务器，必须避免对服务器物理位置的依赖。

架构中的层

两层结构的系统
指C/S架构的程序。通常指包含了展示和业务逻辑的客户端和服务器上的数据库。展示和业务逻辑紧密结合。

优点
安全是一点，由于这些系统是位于防火墙后面，员工不能使用不安全的的PC。性能通常比较好，如果公司不使用比较老的很少内存的电脑的话。

缺点
可用性是一个缺点，因为如果一个元件不能工作的时候，整个系统就变得不可用。
伸缩性是一个问题，由于维一能够增加的元件是数据库。
为了能增加新功能，你很明显会影响到其他元件，扩展性不行。
可管理性也是一个问题，监控所有正在运行客户端的PC是不可能的。
可维护性和可扩展性一样。
可靠性不是一个优点或缺点，由于请求增加时，所有的这些请求来到数据库，所有的数据库能处理增长的交易吞吐量。

三或多层架构的系统
三层架构由WEB，业务逻辑和资源层组成。多层架构的系统有WEB，业务逻辑，整合和资源层。在非功能需求方面，三层和多层架构的系统拥有相同的优点和缺点。

优点
当将展示层逻辑从PC客户端移到服务器端，而能被集群时，伸缩性被改善了。
由于集群层能够提供失败转移机制，可用性也有所改善。
由于功能被分解到不同的层中，扩展性也有所改善。你可以更改表现层又能使得对业务逻辑影响最小。
对于可维护性也是这样。
由于各层是部署在服务器上，使得监控各个元件变得更容易，这样可管理性也提高了。
分层对于安全性可以做得更多，但必须小心对性能造成影响。
性能可能是优点或缺点。主要还是优点，当分割线程到各服务器上时，如果你要在服务器间传送大数据时，这时可能会变成缺点了。

缺点
多层系统原生是比较复杂，多层架构的系统其实是没有所谓的缺点。虽然这样说，并不会由于你有了多层设计，你就有了很好的架构。必须记得不要过度使用层数。

小结
架构是一系列的使得系统能够由一组具有自己的上下文的简单的子系统组成的结构规则。

性能是指系统的响应时间，如必须在3秒内响应。

伸缩性是指当访问量增加时可以增加冗余的组件，部署到增加的服务器上时，原系统无须作更改。C/S结构的系统，由于系统安装在客户端，就不能作这种伸缩。

扩展性，是指增加或修改功能时对现有的系统不会构成影响。如MODEL1的情形，系统没有分层，所有代码混在一起，更改时会互相影响。

可靠性，是指访问量增加的时候，事务有保证。通常数据库对增加的请求，事务的保证方面已经是有所处理了。

可用性，是指系统中的某个元件失败时，系统还能访问。如果是C/S架构的系统，无法分层，某个元件出现问题时，系统就不可用了。

可维护性，是指调整现有的系统流程，不会影响到其他元件。

可管理性，是指能监控系统伸缩能力，可靠性，可用性，性能和安全。

安全性，是指系统能够阻挡非法访问。

paulwong 2012-07-23 17:58 发表评论

读书笔记-架构

paulwong — Thu, 19 Jul 2012 08:19:00 GMT

一、什么是架构

架构就是系统的结构，是一种机制。

架构就是系统的结构。你建立架构来解释将来系统的结构和这种结构如何支撑业务需求和非功能需求。你可以定义这种结构作为一种机制，系统如何用来解决一些普遍问题。这个机制有能力以统一的方式支持业务需求。例如，持久化机制必须被系统统一使用，这意味着，任何时候系统如果要做持久化，必须以同样的方式。将持久化机制定义后，你就提供了一种默认的所有设计人员必须遵循的方式。这些架构体制，如持久化、分布式、通讯、交易管理和安全就是你建立系统的基础，而且必须得建立的。

什么是建立架构呢？就是你建立的符合系统中规定的非功能需求的基础。例如，系统中说明对用户的反应时间不能超过3秒，你建立的软件基础就必须符合这个需求。这同时也意味着你已经给设计人员一个允许他们设计和编码来建立系统时而不必担心这些非功能需求。一个关于架构中比较真实的问题是：架构的建立什么时候停止，设计流程什么时候开始？对于每个系统没有最终答案。这个架构和设计的问题可以被总结起来和控制。架构定义了将会建立什么，设计了你怎样建立系统的外框。一个或少数人关注全景来控制架构的流程，其他多数人关注如何实现全景是设计所要控制的。架构师设计架构，设计团队在这个架构中用它来达成系统的全部目标。因此，如果你正在为有经验的设计人员建立架构，你就不必象为缺少经验的设计人员那样提供尽可能详尽的文档。

当你在建立架构来没跟系统的非功能需求时你通常不会有无限制的资金来购买硬件、软件和开发资源，因此你必须使系统能在有限的预算中很好的运行。例如，当你只有一台电脑来支撑内部用户时，你怎样建立可拓展的系统来满足互联网时代？没有资金来购买软件产品时，你怎样建立架构？这些就是架构师们建立系统架构时面对的问题的例子。你会面临很多困难的选择，和做很多取舍来解决这类问题。由于你作了取舍，很重要的是取舍你必须用文档说明，使得开发人员能够理解为什么要作这个取舍，这样你就不会收到来自开发人员的问题了。如果你决定使用ORACLE在系统中，你就必须用文档注明为什么要选择ORACLE而不选其他数据库。你建立架构时的取舍关注非功能需求。大多数系统没有足够的资金来满足所有的非功能性需求。作为架构师，你就必须平衡非功能需求和预算之间的矛盾。如果要做24*7的高可用光是购买硬件花掉了你全部的预算，那就是说没有多余的钱来购买应用服务器来维护非功能需求了，你就必须调整你的软件架构了。调整依赖于你正在建立架构的系统和与投资人的关系。

二、架构师角色

架构师必须具有以下特点。

架构师必须是一个全面的，成熟的，有经验的，受过教育的，学习迅速的，一个领导者，很好的沟通，和在必须时候作出困难的决定。全面的是指，架构师必须具有业务和问题领域的工作知识。他们能够通过经验和教育获取这些知识。另外架构师也必须具有广阔的技术知识。一个好的架构师能够评估所有可能的方案不管使用何种技术。

架构师要做些什么？架构师与资深开发人员有什么不同？这些都是一些常问的问题。设计师考虑一个用户按下一个按钮时将会发生什么，架构师则考虑成行千上万的用户按下一个按钮时将会发生什么。架构师要减轻和系统相关的风险。技术风险可能是未知的、未证明的或未测试的。风险来自非功能需求，有时也可能来自业务需求。不管哪种风险，都很容易地尽早地在建立架构阶段指出这个风险。

架构师必须领导开发团队保证设计师的开发人员根据这个架构一构建系统。关于取舍必须作出困难的决定，作为领导者，就是作决定的人。为了领导项目团队，架构师必须是一个好的沟通者，包括读和写。通常是通过虚拟模型和群组讨论。如果架构师不能很好的沟通，设计师和开发人员也许不能正确地构建系统。

paulwong 2012-07-19 16:19 发表评论

什么是高内聚、低耦合？

paulwong — Mon, 16 Apr 2012 14:37:00 GMT

起因：模块独立性指每个模块只完成系统要求的独立子功能，并且与其他模块的联系最少且接口简单，两个定性的度量标准――耦合性和内聚性。

耦合性也称块间联系。指软件系统结构中各模块间相互联系紧密程度的一种度量。模块之间联系越紧密，其耦合性就越强，

模块的独立性则越差。模块间耦合高低取决于模块间接口的复杂性、调用的方式及传递的信息。

耦合性分类(低――高): 无直接耦合;数据耦合;标记耦合;控制耦合;公共耦合;内容耦合;
1 无直接耦合:
2 数据耦合: 指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言的值传递;
3 标记耦合: 指两个模块之间传递的是数据结构，如高级语言中的数组名、记录名、文件名等这些名字即标记，其实传递的是这个数据结构的地址;
4 控制耦合: 指一个模块调用另一个模块时，传递的是控制变量（如开关、标志等），被调模块通过该控制变量的值有选择地执行块内某一功能;
5 公共耦合: 指通过一个公共数据环境相互作用的那些模块间的耦合。公共耦合的复杂程序随耦合模块的个数增加而增加。
6 内容耦合: 这是最高程度的耦合，也是最差的耦合。当一个模块直接使用另一个模块的内部数据，或通过非正常入口而转入另一个模块内部。

内聚性又称块内联系。指模块的功能强度的度量，即一个模块内部各个元素彼此结合的紧密程度的度量。若一个模块内各元素（语名之间、程序段之间）联系的越紧密，则它的内聚性就越高。

内聚性匪类(低――高): 偶然内聚;逻辑内聚;时间内聚;通信内聚;顺序内聚;功能内聚;
1 偶然内聚: 指一个模块内的各处理元素之间没有任何联系。
2 逻辑内聚: 指模块内执行几个逻辑上相似的功能，通过参数确定该模块完成哪一个功能。
3 时间内聚: 把需要同时执行的动作组合在一起形成的模块为时间内聚模块。
4 通信内聚: 指模块内所有处理元素都在同一个数据结构上操作（有时称之为信息内聚），或者指各处理使用相同的输入数据或者产生相同的输出数据。
5 顺序内聚: 指一个模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素输出就是下一功能元素的输入。
6 功能内聚: 这是最强的内聚，指模块内所有元素共同完成一个功能，缺一不可。与其他模块的耦合是最弱的。

耦合性与内聚性是模块独立性的两个定性标准，将软件系统划分模块时，尽量做到高内聚低耦合，提高模块的独立性，为设计高质量的软件结构奠定基础。

有个例子很容易明白：一个程序有50个函数，这个程序执行得非常好；然而一旦你修改其中一个函数，其他49个函数都需要做修改，这就是高耦合的后果。
一旦你理解了它，你编写概要设计的时候设计类或者模块自然会考虑到“高内聚，低耦合”。

paulwong 2012-04-16 22:37 发表评论

架构师的素质

paulwong — Sun, 18 Mar 2012 18:21:00 GMT

架构师最基本的素质，总结出两点，1是技术知识广度，2是业务行业深度。

1 架构师是技术领导。
架构师必须要有技术，而且还是领导。架构师要带领自己团队完成自己的任务，完全凭借自己的能力做事情，完全是匹夫之勇，根本不提倡。

2 架构师理解软件流程。
架构师必须了解软件流程，否则无法驱动整个团队前进，如果一个架构师不熟悉开发流程，无法协调产品线相关人员进行高效工作，也无法指导团队成员完成自己的工作。所以来说架构师一般不是空降兵（除非是全新的部门），因为空降兵一般不会熟悉新公司的开发流程，即使是同一个行业的，各个公司的差别还是很大。所以说听说某某去某某公司做首席架构师或者首席科学家，一般是高风险的事情，即使他对这个行业很了解。

3 架构师必须熟悉业务领域。
如果一个架构师不熟悉自己的行业，做的架构就是纸上谈兵，熟悉业务领域的架构师，才能很好的理解需求，做出合适的方案。互联网和网络安全是完全不同的两个方向，即使你熟悉里面的各种具体技术，但是以互联网的架构来做网络安全产品，肯定是100%的失败。
我做PKI的时候，项目最初的使用.net，使用微软的crytoAPI，开发的很顺利。后来来了一位新的架构师，觉得.net不能跨平台，决定?用java，做出产品后，发现找不到arm cpu的jdk，使用平台有限。再次决定使用openssl做，最后这个项目以失败而告终。后来我想过arm cpu都是嵌入式设备用的，根本没有任何嵌入式设备提供CA服务。

4 架构师必须要有广度的知识。
架构师考虑的问题必须全面，必须了解的要广，具体的细节可以不关注，因为细节变化很快。很多具体技术人员出身的架构师，只关注于具体的细节，某些方面做的很好，整体的性能很差。
下面这个项目的成功可以理解为一个笑话。某公司的两个部门都做c程序的，A部门做的平台使用的x86和mips，B部门使用平台是x86和 arm，后来A部门的一个模块要给B部门用，最后发现根本不能运行。最后A部门发现arm平台使用big endian模式，这样A部门的20多名员工，检查代码中所有非零整数，经过数个月苦战，才修改完毕。其实解决方法很简单，因B部门的代码也是首先在 x86做的，做的时候他们考虑了cpu的endian模式。这并不能说B部门架构师很牛，从另一个方面说他的无知。因为板子有跳线，专门切换cpu的是 big endian还是little endian，这样两个部门都可以不修改程序。

5 架构师必须是写程序的高手。
架构师一般都是?发人员出身，一般都是团队的核心。优秀的架构师应该了解团队使用各种技术，有了这些知识，才能和开发人软进行有效沟通。
有一个项目架构使用xml做配置，因为病毒库很庞大，最后导致xml 达30多兆，服务端的java程序使用dom 进行过滤的时候，30兆xml加载很慢，频繁出现out of memory。这个项目后来搁浅。根据以前的经验发现 msxml加载30多M的xml 不过几秒，而且msxml的xpath速度很快，后来专门为此写了JNI处理xml的。

6架构师是优秀的沟通人员。
架构师一定要会忽悠，至少要扯淡。架构师不但要指导本部门员工的工作，也要协调其他部门的资源，还要向用户收集需求，制定规格说明书，重要的把用户的不合理要求砍掉，合理需求遵循自己的思路

paulwong 2012-03-19 02:21 发表评论

软件架构那点事儿（二）

paulwong — Sun, 26 Feb 2012 12:47:00 GMT

什么才是软件架构呢？这是一个让人费神的事情，其实呢我觉得“软件架构”至少应该是一个动词，而不是一个专有名词。那么什么才是架构呢？按照我个人的理解，架构这玩意简约不简单。“架构”的过程是一个把抽象转化为具体，其中的美妙不会低于设计师创造艾菲尔铁塔那般的感受。架构的过程会让你变得偏执、疯狂。至少在短时期内会为之寝食难安。那时时候你的世界之后架构二字了。有点长，希望耐心看完～～～哈哈！

（PS：尽管架构是与编程语言无关的事情，目前采用Java语言作为例子）

好了，很多人读到这里会怀疑，难道J2EE业界流行的那些SSH、SSI 不是架构吗？我的回答是“NO”，如果硬要如架构沾边的话，那也充其量是一个架构最最低级的一种。在现在的我看来，那些只不过是一些开源框架的简单集成，毫无技术含量可言，对于架构者本人而言，那就是通过固化的配置把这些开源框架进行一定程度的粘合，使其能互相配合完成工作。当然不是否认这个配置的过程，但是这个过程是机械化的学习，丝毫看不到自己的想法，这时的想法都被固化的配置所代替。想当年偶也是这样子走过来的，所以说呢，现在的我不敢谈论架构的内涵，仅仅是表达出我对架构的一些想法。文以记之。

好了，经过SSH简单的粘合之后，感觉自己很伟大，而且看是跃跃欲试的样子，拿来做项目，这是必经的一部，从程序员到架构是一个设想与实践相结合的一个过程。你自己架构的东西必须通过项目的实践，才能了解是否有改进的余地。我是比较幸运的，一直以来很多项目都是我架构之后在实践呢，在这里感谢那些曾经呆过的公司。是他们给的平台才让我有今天坐在这里写文章的冲动。很多人在使用简单粘合的SSH框架去架构你的项目，你会发现那玩意不适合做项目，太原始了，仿佛回到了石器时代，当然当时你的水平估计也就是才进化到铁器时代吧。

第二阶段了，开始尝试修改SSH搭建的框架，新在而言还是用“框架”来形容比较的贴切一点。通过一轮或者几轮的项目实施，你会发现其实SSH等这些也不是很完美，至少还有很多地方可以改进，这时你已经不再满足于SSH的简单那粘合了，开始尝试去修改加工SSH的粘合。增加一些与SSH直接交互的隔离层代码，这样一来自己项目的代码干净了很多，SSH从入侵式到非入侵式（不可能100%），这已经是一个了不起的飞跃了。你发挥了作为人主观能动性的权利，现在你收获了。那改造的SSH继续项目到项目中去实践，也许改造后的架构在当时的你看来已经很完美了。勇者无惧，Going，开始第二阶段的试水，感觉很好吧，现在的你也许长大一点了，不再从单一的技术去看待项目了，开始考虑项目的开发计划了，有了后则一层的考虑说明你是一位勤奋好学的好孩子，已经不再是单纯的Coder了，面对计划，在看看自己的架构的“框架”，时间紧迫啊。用这玩意尽管目前代码尤雅了很多，但是对于项目小组成员的开发进度还是帮助不大，大家需要学习的东西太多了，Spring、Struts、Hibernate ....... 这对于经验不是很丰富的程序员而言，简直就是噩梦。考虑到这一点，你就开始进入第三阶段的进化了

第三阶段，开始思考屏蔽各种框架集成带来的复杂性，让不懂SSH框架的人也可以快速上手使用，为了达到这一点，又开始废寝忘食的框架重构，增加更多隔离层的代码。这时的框架有点架构的味道了，重构之后的你会洋洋得意，认为这是很完美的了，又去屁颠的拿去项目实战了，这时发现你隔离之后的反而适得其反，百思不得其解啊？什么情况呢？因为你对粘合的框架内核机制不了解，这时的你要虚心学习那些开源框架了，必须是源码级别的阅读，了解他们的内核机制，才能写出更好的隔离层，面对大量的源码，必须有个入口吧，下面我简单吧Spring的入口告诉大家：首先是Spring的Ioc容器，这是核心，主要是看init bean以及loadbean的这点内容是精髓，Aop的话比较深入了，简单一点就是采用动态代理方式实现AOP，在高级的就是采用CgLib的动态代码切入实现。学好这两个之后。在学习Spring MVC 了，这是一个难点，你要吧Mvc的解析流程整理好了，在从每一个环节思考架构为和要多一个这样的环节。（Struts1 太简单了，Struts2太复杂了）。言归正传了，经历一轮源码的洗礼，你脱胎换骨了，SSH对你而言使用起来游刃有余了。你再也不用为框架不熟悉费力了，这是的你充满了自信，短期内不再关注学习框架了，更多的时间分配给了架构。这时应该进入第四阶段了吧

第四阶段，开始用全新的眼光以及思维去粘合SSH，不错，很多以前的使用不当现在都让你轻易的化解，而且开始考虑使用SSH特有的一些优势去美化的你的架构。现在的你开始考虑的不是开始了，而是如何保证代码的质量问题了，如何保证呢？好吧，找领导申请资源测试吧，对不起，测试团队是很昂贵的，公司很少会配备测试团队的，自测？小弟们才不会如此上心呢？未雨绸缪吧。架构时候为何不架构一套基于SSH的单元测试框架进来呢，好处呢可以脱离容器去测试功能，基于框架的单元测试进入了你的思考范围。等从思考到完全融入架构的时候，你有进入一个新的阶段了。编写测试架构就是为了提高工作效率，目前面向Web的开发，很多测试都需要依赖容器，每次启动容器调试是何等的低效啊。好了集成了自己的测试框架，小弟们高兴了。也会对你刮目相看，至少编写单元测试是一个程序员的义务，保证自己的代码的稳定性，现在你轻松了，每天吧小弟的成果用写的单元测试运行一次。没问题了，不错。下班。

第五阶段，也许这一阶段你的架构开始稳定，很长一段时间都会固化不变，也许到达了一个瓶颈了。单位来了狠多项目，每次你都构建一个基础成，1次 2次。。。N次，O-MyGod，你开始讨厌这种重复的的劳作了，得，这是你的责任，你是公司的技术一把手，这些肯定有你来做。这是你开始考虑吧基础层与业务层开始解耦。解耦出来的东东作为单独的一个项目存放，自己手动维护，以及版本控制。新建的项目都依赖你的基础项目在做业务开发，现在感觉好多了，不用在为项目每次都搭建了。看着别人在忙，你在一边抽烟偷着乐吧。新在的你体会到一丝分离的快感。这不是就是所谓的程序的解耦吗？这不过你解耦的比较彻底了，从功能和物理上都实现了解耦。恩体会到设计模式的优美了，这是你也会才会发自内心的去迷恋设计模式。这些设计模式是前辈们精华的抽象，不同的模式用于解决各种现实的业务建模。学会是一回事，灵活掌握是另外一回事。关于设计模式，是必经的过程。不仅仅是学会，关键是灵活使用。在合适的场景下选用合适的模式，才是正解。

第六阶段了，通过之前的积累，你已经开始迈出走向架构的第一步了，之前都是为这一步的积累。好比是砍柴，之前都是磨刀了，现在才开始踏上砍柴的路途，哼着儿歌、一路进发。现在刀不是问题了，估计之前的砍柴都是刀不好，注意力都在刀上了，现在刀是没问题了，开始转移到观察柴了，什么柴比较好，砍哪里可以一刀成功，这些多是经验。映射到软件项目就是，开始关于业务建模，不同行业的业务都有其自身的特性，如何针对这些特有的业务特性去架构框架呢，在之前的隔离层上在封装一层业务支撑体系，这个体系可以良好的为业务系统提供强大的动力。通信、政府、金融、医疗、企业、税务、电商。。。。等等，每种行业有有其自身的业务特色，干活去吧，都发现架构的不足了，那就继续完善吧。coding～～～～～好了，针对业务的支撑层也开发完毕了。通过实践运行不错。。。。。这时你的框架成了公司的某一业务线的开发平台了。。。。如果继续留在公司，你也许会不断完善其业务建模的支撑体系。可惜，你可能换工作，换工作就意味这换行业。之前积累的业务体系完全行不通啊～～～悲剧了，没办法，从小弟开始做起吧，虚心学习业务基础。。。。

第七阶段，跳槽太多也不是坏事，经历了几个不同的业务线，你敏锐的嗅觉开始体验到一些独立与业务之外的程序处理规则。如何能搭建一套快速满足不同业务建模的基础模型出来，说到底业务到了底层还是各种流程，只是每个流程节点处理的内容不同（不是工作流，但有其思想）。这时候，你考虑的问题已经不是业务建模了，而是业务之外的东东，这个时候你会忘记SSH这些所谓的框架，这些都是具体的形式体现，现在你需要的是高度的抽象，抽象业务之外，流程图是你研究的核心，因为任何程序其实都可以用流程图去表述，如何开发一套流程配置解析引擎呢，神码业务都是流程上的一个节点而已。只要业务流程化，按照我的配置写入，那么他就可以运行。见山不是山的境界吧哈哈～～～到了这一步了，感觉架构才是正的开始了。当然框架是抛不开的，现在面临的问题就是如何利用既有成熟的框架是完成你的这些构想，现在的框架开始考虑自己的分层了，内核层、安全层、缓冲层、ORM层、异常处理机制、国际化机制等等，是不是一项伟大的工程呢，也许Spring就是这样子走过来的。完成了这一阶段的修炼。那么你还不满足吗？恩的确有点就是说不出来，总是有点不满足。现在开始讨论更深层次的话题

第八阶段，架构是有了，你的项目规模也越来越大了，用这个玩意的人也越来越多了，现在考虑的是如何把你的框架能快速推广，市场是检验产品最好的标尺。是否具有可用性。是否能量产程序员（入门级），是否能保证代码的质量、是否能保证出现问题的快速定位，是否能够满足业务扩张的需求、是否满足性能的要求………………….. 咳咳～～一口气说完太累了！！这些问题是现在需要考虑的问题了。现在架构的推广不仅仅是你的团队在用，也许其他团队也在用，可惜他们无法得到你的亲授，肿么办?开始文档化、标准化、提供实例Demo，这些够了吗？对了还不够，100个程序员有100中独立风格的编程方式，那就意味这有100个风险的存在，你的架构如何屏蔽或者降低这些风险呢？答案呢？就是要用你的架构去诱导他们尽量编码风格一致。其好处不言而喻啊，统一的编码风格意味这每个程序员都是平等的，从项目角度考虑，那就是把人的风险降低了（包括离职风险）。带来的另外一个好处就是Review代码的快捷，统一风格的编码无需讲解 ……. 自己体会吧。说再多也是没用这个要亲自体会的。到了这一阶段感觉自己是什么？在雕琢一个艺术品？哈哈～～这个时候更加需要实践，去完善你的架构。因为现在你的架构是真正的架构吧。这个需要天时地利人和多方面的支撑。能达到这一步的程序员需要的不仅仅是自己的努力了，也需要公司的大环境……………….. 这就是为何什么程序员需要找适合自己发挥的平台。公司成了员工技术发展的桎梏。其结果就是让其平庸，或者释放去更宽广的空间。哇塞。好长久的文章啊。读者看到这里，需要休息休息了，找几张美女图片看看吧～～～也许我的文章让你费力了。现在OK了吗？架构可以了吧。恩还是有差距的。

第九阶段，见山是山，再次回归项目中来，项目的目的是什么，盈利。这是最本质的东西。偏执也好、狂热也罢。这是一条基准，违背这一原则的任何架构都是失败的架构。盈利不是结果，而是项目每一步风险规避的积累。架构这是需要考虑的就是如何让架构能在每一阶段都能起到规避风险的功能呢？这是一个比较空洞的概念。但是这是必须考虑的，涉及到架构任何一个细微之处的调整。从项目开始到投产到维护。。。。这个过程，架构如何能保证每一阶段的风险规避呢。或者提供解决风险的更好的方法 ………………………..

上述为架构师修炼的过程，架构是具有中国特色的架构。不同于国外，一些老外闲的蛋疼去研究，我们都是苦逼的项目中提炼自己，利用8小时睡觉，8小时工作之外的时间去完成这一修炼，上面的文字也是本人的程序开发的成长历史，抛砖引玉吧～～希望能对开始“架构”你提供一些参考。最后浓缩几个字，算是文章的目的！

盈利、重构、坚持。

paulwong 2012-02-26 20:47 发表评论

软件架构那点事儿（一）

paulwong — Sun, 26 Feb 2012 12:44:00 GMT

关于标题，我也开始附庸文雅了。哈哈！话说软件架构是本人这些年的一些积累，在此做一点分享，希望对即将做架构或者是正在架构的 ITer 一些参考，也许见解浅薄，还望大家多多包涵，如有异议，可私聊，禁止拍砖。

说起架构可不是一件简单的事情，他是一个很庞大的系统骨架，但是面对到手的软件需求，你是如何设计一个合理的架构呢？原来架构这玩意也是分第一步、第二步、第三步 ........ 以此类推，不能急于求成，这样容易扯着蛋。要做到手中无剑，心中有剑的境界，并非一朝一夕的努力，需要长期项目的实践，经历无数次的失败与重构之后再能叩开“软件架构”这个大门的一丝门缝，从来一窥汪洋。

拿到一个软件的合同或者是用户的最原始的需求，很多架构师的第一直觉就是关注软件本身的功能，有哪些功能，适合采用哪些技术选型。这对于大多数人而言，的确是没有错误。但是在这之前还一点需要去做的事情 ...... 不知道大家想到了吗？架构是基于什么环境呢？这一点在架构之前不知道读者现在是否思考过这个问题。所谓的架构首先要了解软件运行的软硬件以及网络环境。之后明确了这一点才能考虑下一步的事情，否则就有点闭门造车的感觉了。

好了，说到运行环境，这是就要从硬件环境与软件环境分别对待了，例如：

1、硬件是采用几层架构啊，是采用集群还是单机部署呢？典型的网络架构是Http服务器 + Web服务器 + 数据库服务器。比较厉害的就是这些都放在一个机器上哈哈～～～

2、软件运行的网络环境如何，是基于局域网还是公网呢？是否存在隔离的情况

3、硬件是什么机器呢？IBM刀片还是 AIX系列呢
4、系统的灾备设备是什么，如何运作

......... 等等诸如此类的硬件环境首先要了解。

硬件明确了，下来考虑软件环境

1、软件运行的环境是 Window 、Linux、Unix ，是32位 /还是 64位

2、软件运行的Web服务器神码 WebSphere？Weblogic、Jboss、Tomcat、GlashFish还是别的？版本号是多少，支持的J2EE规范是多少。

3、JVM是什么版本，是全新部署还是复用甲方已经存在的软件环境呢？
4、软件是否与其他软件有数据交互，交互采用什么介质

5、采用什么数据库，版本是多少？

.......... 这些是作为软件环境需要考虑的一些基础性的问题

通过上述简单的文字，好像大家有点明白了吧，其实这种事情，很简单的，只要平时多注意点就OK了，否则等开发后去现场实施才发现什么都不配套啊。如果在架构开始之前，你已经关注这一点了，恭喜了说明你已经具备作为架构师最起码的嗅觉了。

上述的那些问题或多或少影响架构本身，架构是基于单机还是基于集群，这是两种迥然不同的架构模式，很多天真的童鞋认为单机与集群架构差不多，复制一套在部署一台机器就OK了。其实则不然。二者存在太多的不同了，我举一些简单的例子哈：

在Java行业，很多开源软件使用很频繁，这些开源软件本身集成了Cache，用于提高性能，单系统是单机运行的时候，一切都正常，做了集群出现问题了。Cache 惹得祸，因为你的集群并没有把框架内部自带的缓存集群化，还是保持各自独立的状态，一用户通过A服务器修改了内容，并且刷新了Cache，但是作为集群的B服务器感知不到A对Cache的变化，依旧从自身的缓存中获取“脏数据”，这时其他用访问B服务器读到的值，其实是A用户通过A服务器修改之前的值。很绕吧。希望能理解。瓦咔咔～～～这是架构如果采用cache 需要重写自己的Cache框架，必须屏蔽开源项目中自带的Cached，否则出了问题都让你莫名其妙？

数据库部署是单机还是双机，是热备还是冷备，数据访问需要读写分离吗？如果硬件不支持数据库热切换，如何采用程序实现数据库的热切换？这些都是架构层次的需要直接面对的问题？架构师们你们心里有底吗？

与甲方内部的其他系统是采用什么通信方式？Socket、WS、RMI，访问的系统之间是否有防火墙隔离，采用什么技术可以穿透防火墙阻拦呢？

以后的系统如何快速部署到对甲方的真实环境中，是手动部署还是Ant自动部署？如何做到持续集成？发送错误如何回退？

......................... 现在是不是觉得有点复杂呢？其实没关系，成长有两种，一种是汲取别人成功的经验转为为自己的能力，另外一种是尝试失败，从经历失败中成长，本人呢二者兼有，前几年都是从失败中成长，但是随着时间的推移，发现这样的代价真的是很大。开始虚心学习前人的经验，从而转化为自己的知识。

掌握软件运行的软硬件环境是作为架构的第一步，切记切记！

上述文字，仅仅是作为软件架构之前需要考虑的一些大概，还有很多细节其实我也不是很了解，如有补充请回帖瓦咔咔～～～～软件架构是一件艺术品～～～这是我对架构的感性认识。

每次架构完我都会在一段时间把它当作是完美的艺术品去欣赏，过了新鲜期后，发现很多问题，直接重构这样循环不已 ............. 每次的迭代都让自己收获很多！

paulwong 2012-02-26 20:44 发表评论