本文对我最近参加的架构师培训内容进行整理记录。

通过提问，老师总结同事们广泛关注的焦点内容包括以下几个方面：

设计过程基本上分为两个步骤：

1. 静态架构设计：模块划分、模块结构的分析、组件结构的分析、并发的设计、部署的设计（主要针对分布式系统）、分层设计、接口设计（WebService、RPC、数据共享）、通讯设计（主要是协议的选型，当然也牵涉到前面的技术选型）。这基本上是很多架构师当前正在做的事，但是可能没有做的这么细。类似于温老师的架构五视图，个人觉得概念不够精炼，但是可能比较实用吧
2. 动态架构设计：这个主要是牵涉到系统的底层框架，主要满足非功能需求，包括健壮性、高性能、可扩展性，这里会介绍接近20种架构框架（架构模式），一般都有对应的开源框架，这一部分老师认为是最重要的、也是缺少具体书籍的，主要靠经验积累

上述20种框架，其中2-3种与解耦有关，解耦对某些系统特别重要，一旦代码量大了，可扩展性、可维护性问题会变得很严重，因此老师不管在考虑什么架构问题时，往往会首先想到解耦的问题。解耦问题解决了，很多东西会变得简单。

性能往往和数据有关，需要考虑如何处理数据让性能提高，这里包含5-6种框架，这些框架是比较重要的

其实很简单，如果掌握了静态、动态架构设计，你很容易看到系统中存在哪些缺陷。

重构的流程：看原有架构的问题 ➪ 改进的设计 ➪ 新的架构方案 ➪ 风险评估 ➪ 执行重构  ➪ 功能非功能测试  ➪ 系统试运行

为什么觉得重构困难，主要是架构级重构需要对系统具有全面的把握能力。

重构不一定是架构级的，也可能是模块级、代码级的。

1. 软件架构的体系结构：什么是架构
2. 架构的静态设计
3. 架构的动态设计：框架
4. 架构的重构问题
5. 架构的管理

架构是什么？很多时候是系统的结构的定义，很多时候我们都认为架构是功能性的，例如功能模块的划分、如何将其落到层里。往往架构的非功能方面被忽略，这恰恰才是架构最重要的内容。例如在架构里面引入SSH，其实和功能是没有任何关系的，SSH解决的都是非功能问题。例如可扩展性、解耦。在比如房屋的建设，不是首先考虑那块作为卫生间、那边作为卧室，首先需要考虑的是房屋的框架结构，这些结构对房屋的功能无益、没有业务架构，甚至是有妨害的，例如立在房间中间的柱子。软件设计也类似，首先需要满足非功能需求，在满足非功能需求之后，才会满足功能需求。

架构的过程，是系统结构的定义，这个定义分为两个部分：

1. 关注点隔离：高层分割，按住业务特性分成不同的部分。这是依据人类自然而然的分类思维来进行的。这样的关注点分离可以简化问题（床与房间的例子）。这种分割应该合理、易于别人理解，这种分割很多时候按照功能性进行的，其依据是需求，首先将系统划分为不同的关注点，或者叫业务模块
2. 当把系统分隔为不同部分后，往往会发现一些通用的部分，这部分往往对应了非功能需求。不同的非功能需求，例如可扩展性和性能，本身就存在冲突，这里就牵涉到权衡

架构定义的引入，有几种定义方式：

1. 架构组件划分，以及组件之间的关系、交互，这是当前很多团队的认识
2. 架构是决策集，以前对决策集的描述都是文字性的，一个严重的问题是这些决策很难被下端业务模块开发人员全部遵循，因此这些决策现在都转换为Framework（例如使用Spring，其IoC、MVC注解体系就限制了开发人员必须遵循架构决策），通过Framework将非功能需求实现出来，结合上层的业务组件，形成架构的组成（Framework+上层组件）。Framework包括其核心设计思想、类图、代码，在大规模开发之前，应该将底层Framework的代码全部做好，然后开发其上层组件。使用Framework后，就形成了业务组件、Framework的分层，两者具有调用-被调用的关系，Framework的代码很少，可能小于5%，但是却大大的降低了开发难度

软件架构要做的第一件事：分解，将复杂的业务拆分到不同的模块，这也是静态架构设计的工作。拆分存在一个粒度的问题，要细致到什么粒度？

随着软件规模的不断扩大，渐渐引入新的封装技术：代码行 ➪ 面向过程（函数）➪ 面向对象（类）➪ 模块（很多类组成，一种虚拟的划分方式，例如Java的Package方式、C++的namespace方式）➪ 组件（在模块基础上提出，具有物理边界，组件是模块的体现形式，比模块细，可以表现为jar包、DLL、Linux的so）➪ 子系统。个人觉得模块、组件的关系比较含糊 ，有时是包含关系，有时是等同关系。

架构的粒度一般精确到子系统、组件级别。

除了组件划分以外，还有去分析通用的、解决非功能需求的框架。这些框架往往在系统间复用。一旦定义了框架，上面上百个业务组件都要使用该框架的API，因而牢牢的绑定这些业务组件的实现方式、落地架构决策。使用框架时，绝大部分复杂性封装在框架中，因此普通开发人员的工作难度大大降低、且代码相似度很高。

软件系统的架构对软件开发有什么好处：

1. 在系统开发之初，就对系统的结构就有了非常清晰的定义——能够从需求实现到系统的静态结构映射。可以映射到什么程度——功能划分到什么组件中。架构上接目标、下接技术决策
2. 有了架构后，可以控制系统的复杂度。首先，底层框架是复杂度最高的部分，但是代码量仅占5%，但是解决了95%的复杂性（解耦的例子）；同时，架构划分了组件，不同功能划分到不同组件中，那么不同模块的复杂性都在各自的组件中（不影响组件间交互）
3. 架构可以组织开发，有利于项目管理。架构划分了组件、接口，可以分配给不同的开发人员完成
4. 可扩展性好的架构有利于迭代式开发，迭代是敏捷开发的重要思想。这当然要求功能解耦、组件化开发，敏捷开发对软件架构的要求很高
5. 架构有利于基于产品线的开发：产品线开发的一个重要思想是平台。所谓平台是Framework+广义功能（即通用功能，我以前的叫法是基础服务）。产品线基于平台构建，产品会有一些自定义的功能实现。老师的产品线建设方式是：
   1. 平台有独立的团队，平台的大版本自己演变。通过可配置来实现具体产品的功能差异化
   2. 需要开发一个产品时，从平台中拿出一个稳定的版本，比如v3.0，在此基础上定制开发
   3. 定制开发的内容形成独立的工程，只在此工程中进行开发，不修改上述迁入的v3.0的代码。此工程的编译结果插入到平台中，形成产品

平台一般都要组件化开发，基本步骤：首先需要提取通用非功能需求，依此定义框架；然后需要提取所有产品的通用功能需求。

架构师到底要做什么：

1. 整体对系统负责：系统的任何部分出现问题，架构师都可以清晰的指出，问题可能出现在什么地方。这个很重要，对于千万行级代码的系统，对于一个普通开发人员，他往往根本不知道自己所做的工作对系统有什么影响（Swimming in codes），这时需要一个全局上掌控的人
2. 在设计架构时，要满足客户需求，包括功能、非功能需求
3. 能够在整个研发过程，能够控制架构，对整个团队提供架构上的指导，协助开发人员的分工协同

软件开发的流程：需求分析 ➪ 系统架构设计 ➪ 得到系统整体的结构定义 ➪  依据该定义进行分工 ➪  由不同开发人员完成每个组件的详细设计和编码实现 ➪ 测试。因此在编码之前，架构为系统提供了整体定义，编码人员可以知道组件之间的关系。非功能需求基本都是在架构阶段去解决的。

架构设计的最终达到的目标：通过底层框架与上端业务模块的分割配合，最终实现利用底层框架来支撑整个业务组件的开发。框架性的代码API强制上层代码依照架构要求进行实现，不仅仅是文字性的指导原则。

好的架构，有一个重要的特点，去除一个组件，不会影响其它组件的正常运行。这样的架构例如Eclipse平台。

这里举了ERP的例子，原料管理与凭证管理。传统的基于interface的解耦有作用，但是是很局限的，主要是接口规格很难稳定。如果使用组件化开发+消息架构，则可以很好的解耦。在原料创建完毕后，需要创建凭证，这时它传递一个简单的消息（可能仅仅包括原料的ID），这个消息被凭证管理接收，凭证管理通过集中数据资源管理（内存体系）获得原料信息，生成凭证后再次通过消息通知原料管理。我觉得这种实现方式其实是观察者的变种，另外即使这样，也不可能完全解耦，在这个例子中，接口规格变化，可能意味着底层数据格式的变化。即使使用消息，原料管理模块也往往必须要修改。当然消息架构适合于模块间/组件间通信，对于模块内则不提倡，这是高内聚（模块内）、低耦合（模块间）原则，所谓高内聚低耦合实质上说的是一件事情，就是对象之间依赖关系的强度。函数调用是属于强依赖，调用次数越多，则内聚越高。模块内的类之间本身从业务上就是互相之间强依赖的，因此适合高内聚；模块间的类则从业务上说，关联相对较少，模块A的修改应该尽可能避免牵涉到模块B。因此适合低耦合。

观察者模式是一种间接调用的思想。老师比较反对通过MOM传递数据（消息），认为MOM传递消息的成本较大，建议只传递对象的标识符。

业务架构的实现过程。业务架构来源于需求，很多团队做需求存在问题：需求没有层次，是一块大饼。其实需求分为几个层面（老师称为CFSU）：

1. Concept：高层概念。定义了大方向，系统干什么？不干什么。简单的说，高层概念往往对应了一级菜单
2. Features：特性，功能。具体的一个个业务功能，往往对应二、三甚至四级菜单
3. Scenario：每个特性下的场景，每个功能至少有一个业务场景
4. Use cases：每个场景下的用例，依据业务场景分析出的软件操作步骤、界面、业务逻辑、数据

这四个层面是自上而下、逐层分解。我们通过这种类似于剥洋葱的方式来一层层的分析需求，思路会很清晰，可以避免一片混乱的、跳来跳去的大饼式分析导致功能点遗失。

业务架构往往只需要涉及到1、2层，下面两层属于细节的业务需求。今天国内很多架构团队能做到的，也就仅仅是业务架构这一部分，静态架构、动态架构没有涉及。业务架构本质上应该属于系统分析（Systems Analysis）。

业务架构阶段，首先需要把需求分析清楚，然后使用UML将其建模出来，形成业务架构文档。业务架构需要做以下几个分析：

1. 系统间的数据关系分析，这个我们称之为上下文（Context），使用UML包图表达
2. 业务模块的调用关系分析，这个我们称为业务组织图（Business Organization Map，BOM），使用UML包图表达
3. 功能的流程、前后关系分析，这个我们称为业务路线图（Business Road Map，BRM）使用UML活动图表达
4. 此外，还应该进行领域模型分析（DMA），可以使用类图表达，描述核心实体类的关系

出这三类图之前，需要把Concept、Feature都列出来。那么如何能不遗漏的把Concept、Feature都列出来？

1. 首先，我们要做项目的背景分析，分为两个部分：业务域分析、价值链分析，这个做完后应该得到系统的所有Concept
2. 有了Concept之后，就可以基于Concept进行Context、BOM分析
3. 之后，需要分析每个Context下的Feature
4. Feature分析完后，可以进行BRM分析

甲方期望建设一个第三方支付平台（xpay），该平台共互联网上的商户、消费者使用，此外甲方还期望基于此支付平台建设一个电子商务平台（xeb）。

需求访谈的一些技巧：（我自己总结的）

1. 尽量使用客户的行业语言，或者简单的语言。不要出现太多技术性名词
2. 尊敬客户，不要无意识的让客户承认其自己的错误，让客户难堪。记住客户是付你钱的，是上帝
3. 为客户着想，让客户看到系统能给他带来的价值、利益
4. 复述、需求确认，特别是使用易懂的流程图复述
5. 引导，对于客户不合理的需求，应当适当引导、变通，而不是生硬的拒绝
6. 整理记录，如果允许，最好录音

通过需求访谈来了解项目背景，需求获取是比较依赖于行业经验的工作，最好由行业专家主导（讲课过程中需求访谈是交叉在业务分析过程中完成的，这里做了整理和部分修改）：

客户：我们需要建设的平台类似于支付宝，但是主要是面对商业客户（2B），主要业务包括充值、支付、退款、提现、转账、调账等。（了解到了高层Cencept，要做哪些最核心的事情）此外我们还想基于次支付平台建设一个电商平台，电商平台可以直接使用支付平台的用户/账户（了解到了Context，后面还会继续了解）

需求：即两个平台使用一套账户体系，类似于天猫可以直接使用支付宝？

客户：是的，一方面电商平台可以方便的使用支付功能，另外支付平台可以对第三方系统提供服务。另外我们希望电商平台不需要管理用户，直接通过支付平台的用户名密码就可以登陆

需求：这可以通过单点登录、或者支付平台OAuth解决，电商平台根据OAuth验证结果，可以在数据库中自动生成电商用户

客户：我们不希望电商平台管理用户或者账户

需求：一个用户可以有多个账户么？（关键领域对象的关系）（口吻：不要出现什么one-to-many之类的名词）

客户：目前是有一个就可以了，我们不是银行，不需要管理一个人的多个账户 

需求：充值的流程是怎么样的？

客户：用户将银行卡里面的钱充到支付平台的虚拟帐户中（Context）

需求：这需要银行的配合，需要使用银行支付网关，银行会收取费用

客户：支付网关的商务问题已经谈好

需求：支付业务在什么场景下使用？

客户：第三方商户平台向支付平台发起订单，用户可以通过我们支付平台支付订单，把钱划给商户（Context）

需求：这个业务与充值类似，只是银行的角色改为支付平台，我们可以在收到商户平台的订单后，引导用户去支付。这个支付的钱是来自之前充值的钱么？

客户：可以是虚拟帐户中的钱，也可以直接选银行支付

需求：是否需要类似于支付宝的快捷支付功能 （引导，行业专家的经验）

客户：这个功能很好，我们需要

需求：商户也使用支付平台的虚拟帐户？

客户：是的，任何接入的商户都要在我们的支付平台有一个虚拟帐户，用于接受款项

需求：好的，这样可以做一个类似于支付宝的收银台。退款业务又是怎么样的呢？

客户：消费者在电商平台购买的物品不满意，需要退货退款。电商平台同意后，我们就退款，把商户的钱划回去。用户支付的时候钱怎么来的，还原路返回

需求：如果商户的钱已经被提走了怎么办？支付平台是否需要审批退款？

客户：商户需要缴纳保证金，如果他的虚拟账户钱不够，就用保证金支付。审批退款是电商平台的事情，只要他们同意我们就退款

需求：保证金支付是否需要在平台中自动完成

客户：暂时不需要，人工处理吧

需求：提现就是将虚拟帐户中的钱提走，转移到银行卡中？提现是否需要审核？

客户：提现都人工审核

需求：提现到哪个银行卡，需要预先登记吧？

客户：是的，用户必须首先登记真实有效、实名验证的提现银行卡

需求：用户可以分为商户、消费者两类。消费者可以充值，用来消费商户的商品 ；消费者如果退货，则把商户虚拟账户中的钱原路返回；商户可以对销售收入进行提现。是这样吧？（访谈中对有疑问的地方及时复述，得到用户确认）

客户：是的。消费者也可以提现

需求：我们的支付平台需要和各大银行进行现金交易，因此需要在这些所有银行开户吧？

客户：是的，根据国内法规，支付平台在银行的账户是受到人行监管的特殊账户

需求：商户、消费者在支付平台中的虚拟账户中的虚拟余额，实际是存放在支付平台的银行账户中，当出现提现、充值、退款等业务时，会发生用户银行账户与支付平台银行账户之间的资金转移？（潜在的银行结算模块）

客户：没错

需求：转账业务什么商户做？

客户：用户可以输入转账金额、对方的XPay账号，就可以转账

需求：调账是什么样的功能？

客户：调账很简单，就是增加或者减少虚拟账户的余额

需求：不需要牵涉到银行那边的处理

客户：不需要，牵涉到的其它事务人工处理

需求：支付平台还有什么重要的业务吗？（不要丢失业务域）

客户： 还有风控、费率。所谓费率，是指：一，我们向商家收费；二，银行向我们收费。所谓风控：可以用于指定超过一个什么额度后，就需要记录下来

需求：向所有商户收费的费率一致么？所有银行的收费费率都一样么？

客户：都不一样

需求：好的，我们初步了解了系统的功能，回去后我们整理一个功能表出来，再和您确认

第一次需求访谈到此结束，需求人员回去后进行初步整理和分析（具体参考下面的业务域分析），并得到功能特性清单，与客户进行二次确认。

需求：昨天回去我们把需求整理一下，这是功能表，您看一下：

客户：我们希望充值、支付、提现这些功能作为单独的菜单。另外调账是直接在账户查询中的链接上做的

需求：没关系，后续我们做界面设计时再详细讨论（UI组织与业务模块划分无关，甚至很多开发人员都没有认清这一点）

上面提到，业务架构的第一步是通过业务域分析、价值链分析，来得到系统的所有Concept，尽量避免遗漏。在案例中，老师主要使用了业务域分析技术。

什么叫业务域，就是业务中要干哪些事情。比如对于ERP，我们要做生产管理、订单管理、业务管理……

我们现在做xpay的业务域分析，xpay要干充值、支付、提现等等事情（这里要注意Concept的粒度，不要深入细节）。业务域的分析很重要，任何一个业务域的丢失对系统来说都是很大的风险。

用户管理分析：用户可以自助注册，支付平台的管理人员也可以在后台进行增删改（MIS系统需求分析时要自然而然想到CRUD、启禁）。商户的信息由平台管理人员手工录入，由于商户的信息和用户没有本质的区别，因此引入一个用户录入的功能

账户管理分析：账户对象是随着用户注册自动添加的。与账户相关的功能点还包括提现银行卡管理、快捷银行卡设置。此外处于风险控制的目的，账户还可以被关闭，账户关闭的时候用户仍然可以登录

充值业务分析：一般的流程：用户在xpay中输入充值金额、选择银行后，跳转到银行支付网关页面，与此同时支付平台在后端将银行发起消费请求（订单），这个订单信息会在用户浏览器上呈现。用户在银行支付网关输入卡号密码等信息并支付成功后，银行会将消费请求的处理结果发回给支付平台，同时浏览器跳转会到支付平台。

支付业务分析：和充值业务类似，流程：用户在商户网站上购买商品后，商户调用xpay提供的接口，将订单号、商品信息、金额等信息传递给xpay，同时商户跳转浏览器到xpay的收银台页面，用户可以直接通过帐户余额支付，亦可选择银行支付，如果选择银行支付，则再次执行类似于充值业务的流程。操作完毕后，跳转到商户的回调URL。对于快捷支付，不涉及页面跳转，是通过银行后台接口完成的

退款业务分析：商户平台中发生的退货申请，与xpay平台没有关系，只要商户平台同意退款，那么商户就调用xpay提供的接口，将订单号信息传递给xpay，xpay要么将商户账户的钱划给用户的虚拟帐户，要么将商户虚拟帐户的钱直接划走给银行，即原路退回。

提现业务分析：用户申请提现，审核通过后，xpay调用银行支付接口，将钱从xpay的银行账户划走到用户银行卡中，同时修改用户虚拟帐户的余额。

功能合并考虑：考虑到充值、支付、退款、提现业务上、技术上的相似性，合并为一个模块：交易管理；这些模块都牵涉到的与银行的接口，抽取为银行解散模块。

异常情况考虑：支付平台很多业务都牵涉到金钱，需要相当小心。如果充值时，银行处理成功，但是结果xpay却没收到，那么用户虚拟帐户的金额就偏少；如果提现业务银行处理成功，但是xpay没有收到处理结果，那么用户虚拟账户金额就偏多。虽然这些事情发生几率很小，但都可能导致严重的纠纷。按照行业一般性做法，我们可以进行每日对账，如果银行处理成功，xpay没有收到结果的，执行补单处理。（这个是分析出来的需求，不是用户原始需求）

需要注意的是，在业务分析阶段，不管是用户可见的模块，还是纯后台的功能，都要分析。只从业务角度分析，不管UI的组织方式：即使在单个UI页面上显示多个业务功能、或者没有任何UI，也与业务分析、模块划分无关。有时候用户会期望从UI的角度思考模块的划分（大菜单，二级菜单等），但是我们需求分析、架构人员则不能这么思考，起码在内部文档中，要保证前面提到的模块划分原则。

如果某个UI模块（展现层）依赖于我们这里分析的多个业务模块，那么可以在静态架构分析阶段，在此展现层模块使用多条线连接到关联的业务逻辑层模块。

在业务域分析的过程中，老师从来没有提到使用系统的角色，老师认为业务用例的分析不属于架构阶段，但是我认为既然业务架构本质上属于析分，那么就应该考虑到业务用例的角色。本平台的角色可以分为：平台管理者、消费者、商户、商户系统、银行支付网关等。

在业务域分析的基础上分析业务域的流程，考虑其依赖、前后关系：用户管理 ➪ 账户管理 ➪ 费率管理 ➪ 交易管理 ➪ 风控管理 ➪ 银行结算。

如果出现某个Concept不在价值链上是正常的。价值链可以方便你从高级别理解业务过程的顺序。

借用UML包图（老师推荐使用EA），来描述中当前系统与周围系统之间的数据流动关系，箭头从数据的来源指向数据的目的地。一般自己系统的颜色标记为浅色，外部系统的颜色标记为深色。这张图叫做：System Context。

老师的图只画了箭头，没有标记文字，我觉得使用文字标注数据的简短描述更好。

使用UML包图，来描述系统内部各模块（Concept）之间的调用关系。箭头的方向从调用方指向被调用方。分析过程一般是：找到一个为起点，挨个分析它与周围模块的关系，第一个模块分析完后，再对第二个模块进行上述分析过程，直到分析完所有模块。牵涉到的外部系统也要参与分析。

下图以支付平台为例：

老师的图只画箭头，没有标记文字，我觉得使用文字标注数据的简短描述更好。如果调用关系过于复杂，则可以只画箭头，辅以文字描述

大家可以看到，这么简单的系统，模块间的关系就如此复杂，这个复杂性是没法避免的，因为业务就是这样，除非Concept划分不合理。这种业务上的复杂性可以在设计阶段，利用接口、消息等技术进行解耦，避免模块之间的强关联。

这张图在静态架构设计阶段，将构成业务逻辑层的主体。

在上面需求访谈、业务域分析的过程中已经完成。

借用UML活动图来表示某个模块（Concept）内部的功能流程的关系，这个图中会画出模块中的Feature，并且画出Feature对外部模块的调用。

下图以支付平台的账户管理模块为例：

列出所有领域类，并识别它们之间的关系，列出所有属性。在业务分析阶段可以使用全中文。

支付平台中的领域类包括：用户、账户、银行卡、交易订单、风险规则、费率规则、风控日志等等。

上面我们完成了业务架构，业务架构之后是软件架构，软件架构包括静态、动态架构两部分，分别关心软件的功能、非功能部分。静态架构设计是直接依据业务架构导出的，有时候也称为逻辑（应用）架构设计，该阶段需要做以下事情：

1. 做系统的整体结构的设计。即系统的高层分割，系统分为哪些模块。需要注意这些模块分为两类：系统性模块、功能性（业务）模块。所谓功能性模块来源于业务分析阶段识别出来的Concept、Feature，与业务紧密相关。而系统性模块则是因为技术需要而设计的模块，例如TCP/IP通信模块
2. 进行组件的设计。把模块拆分为不同的组件，如果模块比较小，则可以只对应一个组件
3. 完成接口的设计。接口分为系统内接口、系统间设计
4. 完成通讯设计。老师所指通讯设计，主要是指模块间、系统间通信报文、传输方式的设计。我觉得属于接口设计
5. 进行分层设计
6. 进行进线程设计
7. 进行部署设计。部署设计往往和网络有关，例如路由、交换机、服务器和软件组件之间的关系
8. 把上面几步分析的内容形成4+1视图
9. 进行架构机制（Pattern）的选型，这些选型会称为未来动态架构中Framework设计的基础

我们首先讲述架构机制，因为这一部分很重要。

1. 框架可以提供API，业务模块使用这些API，降低了开发难度
2. 保证架构的执行，保证代码风格一致
3. 解决重复性问题

根据业务特性来识别非功能需求：

1. 可扩展性：期望未来能够方便的添加新功能，互联网应用需要迅速的对市场做出反应
2. 可伸缩性：面向互联网，在某些商户促销活动时，支付平台的压力会陡增，期望能够方便的添加新服务器以增强系统性能
3. 性能：要求能够支持2000Trans/s的吞吐能力，每次支付能够在3秒内完成全部处理
4. 安全性：牵涉资金，需要可靠的身份验证
5. 可靠性：零宕机，每秒的宕机会导致大量的经济损失

识别出来的每一个非功能需求，都是我们的设计目标。有了设计目标后，架构师需要找出对应的技术实现框架机制（即架构模式）。常见的架构机制包括：

架构机制包括三个层次的内容：机制的核心思想、机制的详细设计、机制的代码和API。其中机制的核心思想是通用的，设计以及代码则依据具体实现各不相同。

确定系统需要使用哪些架构机制，可以通过两种分析方式：

1. 自顶而下：架构师非常有经验，直接依据系统特点、个人经验判断使用哪些机制。缺点是可能引入不必要的机制，造成不必要的工作量
2. 自底而上：开始时只使用简单的、必要的机制，根据业务需要，进行架构重构，引入新的机制。缺点是为未来重构的代价较大

根据上一节识别出来的xpay系统的非功能设计目标，可以考虑使用：MVC、IoC、CMF、MF、Cluster、DSF这几个框架机制。

高层分割，即整体结构设计，是系统的横向结构划分，需要践行以下原则：

1. 软件模块中的主要模块，来自于业务模块，即：业务模块会称为软件模块的一部分。任何一个Concept都会成为软件模块，这些Concept会落在展现层、业务逻辑层等层次
2. 所有的机制，都会成为软件模块，并形成Framework层的主要内容
3. 模块的暴露方式应该是接口
4. 模块间要避免循环依赖，如果存在循环依赖，应当使用消息/事件等方式解开

我们知道，在软件工程中，引入新的抽象层是屏蔽复杂性的通用方法。在确定软件模块后，应当进行分层设计，分层是系统的纵向结构划分。分层设计应当践行以下原则：

1. 避免不必要的分层，过多的分层不但降低性能，还增加系统的复杂性
2. 自上而下，逐层依赖，避免跨层调用。跨层调用破坏层的价值
3. 严禁反向调用。在分层设计中，越底下的层越稳定，让稳定的层调用不稳定的层，将破坏其本身的稳定性。以前我们的平台就出现了高层代码入侵的情况
4. 层间应该通过抽象接口来隔离。例如，我们的sshe平台通过自定义的接口隔离Hibernate

注意，架构师并不能完全保证不出现跨层调用，例如使用旧式的MVC框架时，控制层会依赖于Framework层的组件。出现跨层调用时，架构师应当给予充分的理由。

经典的分层模型为六层，足够适用于大部分的系统：

1. 展现层：包含了UI组件
2. 控制层：包含了MVC的控制器
3. 业务逻辑层：包含了常规的业务模块
4. 框架层：包含了所有架构机制，典型的会在框架层之上提供一个抽象接口层API。同时需要进行开源选型
5. 中间件层：包含非平台性质的第三方产品，例如消息中间件、JavaEE容器，一些JDK标准化组件也被老师分在这一层
6. 基础设施层： 包括硬件、操作系统、通信机制

分析后，将上面的分层绘制成图，具体的技术选型使用版型表示，越下面的层次使用越冷的颜色表示。层次间的调用使用箭头表示，如果上层大部分模块都需要调用下层模块，则不必画调用箭头。xpay的分层图如下：

接口设计应当践行以下原则：

1. 接口主要的目的是用于模块间、系统间的通信，分别称为内部接口、外部接口
2. 接口由业务决定，应当逐一分析功能（Feature），来分析哪些功能需要对外暴露，并设计为接口
3. 接口不应当由调用方决定，防止调用方的特殊需求导致调用方的逻辑混入接口提供方，长期下去会导致接口非常多。比如在xpay平台中，交易管理模块不应该直接响应某个模块要求的“查询交易额大于5000的交易记录”
4. 在设计接口时，一个需要注意的是参数的类型，应当尽量使用领域模型而不是基本类型，特别是避免使用冗长的基本类型参数列表，以增强接口的稳定性
5. 外部接口因为牵涉到远程调用，接口的粒度应当尽量粗，避免影响性能

在分析功能以识别接口的时候，应当从业务分析的BOM开始，BOM中已经标明Concept之间、Concept与外部系统之间的调用关系。然后进一步通过BRM来查看各Feature在业务活动中的位置、与其它Feature的前后关系，并从中识别出接口。

 以xpay交易管理模块为例分析：

1. 充值，会被本模块的页面调用，不需要暴露接口
2. 交易查询，会被本系统的其它模块调用，暴露为内部接口：findTransaction
3. 账户支付，会被第三方系统调用，需要暴露为外部接口：doPayment，需要进一步进行系统间通信方式的设计，例如基于HTTP的报文交换
4. ……

接口设计应当完成接口规格的详细规定。

组件是模块的物理实体（往往在操作系统中表现为文件），组件一般是在模块下的细化。组件设计完成的任务类似于温老师的开发架构视图。

如果模块的功能较为复杂，可以根据业务的相关性分割组件；如果模块功能较为简单，可以直接作为单个组件。我倾向于把若干简单的模块划分到一个组件中，避免工程管理的复杂度

组件设计最终使用UML组件图来表示、使用版型说明组件的类型（例如jar、dll、so），以xpay交易管理模块为例：

组件内部可以标出关键的包、类。

并发视图用来说明组件与进线程的对应关系。

实现并发的两种方式是：多进程和多线程，两者的本质区别是后者共享地址空间，性能较高，但是没有多进程安全（单个线程可能导致应用崩溃）、编程难度大。并发本身并不会提高性能，但是由于系统中大量I/O的存在，单线程可能因为I/O阻塞而浪费CPU资源，并发设计特别适用于I/O密集型系统，对CPU密集型系统的性能提高意义不大。

多CPU、分布式、计算的强度、事件驱动、并行计算等会导致并发设计的考虑。 

进行并发设计后，线程、进程一般都会在组件上提体现。我们在组件视图上使用红线框来标注进程、使用红线条标注多线程，并标注并发进线程数量，例如xpay进线程设计的片段如下：

个人觉得，没必要在并发视图上体现出模块与组件的关系，我倾向于使用部署图的Artifact来包围组件，形成并发视图：

部署视图说明组件与服务器、网络的对应关系。

最早的应用程序，后台只部署一个数据库，所有业务逻辑都放在客户端（杀毒软件）；后来发展到后台包含一台应用服务器，客户端处理一些简单的应用逻辑、图像渲染（网络游戏）；再后来，发展到B/S，后端往往包含Web服务器和应用服务器，后者存放业务逻辑层（电子商务网站）。这些都是属于客户端/服务器架构。

除了客户端/服务器部署架构外，还有一种对等网络架构（Peer-to-Peer），它利用NAT穿透技术（UDP打洞），允许任意两个处于NAT设备背后的局域网机器建立通信。这种网络架构一方面可以减轻服务器的压力，另外一方面具有顽强的生存能力。

出于减轻单服务器负载、可伸缩性、更优性价比（二版的反例）等方面的考虑，大型复杂的系统都需要使用分布式架构。

通常网络环境由网络管理部门提供，我们需要在网络拓扑图上标记出组件与网络服务器的对应关系。（我觉得UML构件更合适，组件并不是运行时实体，而且组件可能被部署在多个不同用途的构件中）。UML中的部署图用来绘制部署视图，但是视觉效果较差，可以使用VISIO、亿图等工具绘制。

动态架构设计阶段需要：

1. 根据静态架构阶段的架构机制选型，确定需要使用哪些开源框架，确定需要自主开发哪些框架
2. 对于自主开发的框架，需要完成详细设计和代码编写
3. 补充架构文档

在这个议题中，老师主要讲了一个案例。

NGEP希望能监控全球油田的油井的实时数据（压力、温度、粘度、频谱等），由于这些油井都在荒无人烟的地方，因此数据采集后需要上传到卫星，由卫星转发到位于数据中心的NGEP以便进行处理。NGEP有数千种应用，其中之一：由于地质条件的影响，油井的压力可能突然增高，导致井喷，进而破坏上端设备，为了防止井喷的发生，我们通过监控油管的压力，在到达一定的临界值后关闭油井出口钢板。

NGEP初期准备支持8万口油井的实时监控。数据采集的频率很高、每口油井每天大概产生几百M的数据，数据一般需要保留三年，8万口油井的累计数据最多可到达8000TB，初期准备了200台服务器。经过几年发展，发展到2000万口油井，因此NGEP的系统架构经历了多次重构：

1. 项目简介、预期读者等描述性内容
2. 逻辑视图，并对主要内容进行说明：首先做层的技术实现、职责的说明；然后做主要模块的描述
3. 组件视图，把图中的组件拿出来，形成一张全是组件的图，并对每一个组件进行说明
4. 并发视图，与组件视图是一张图，需要说明组件与进线程的关系
5. 部署视图，并说明组件与物理计算机的关系
6. 通信协议的说明
7. 接口设计，包括内部、外部接口的详细说明
8. 底层框架设计，对使用的所有框架挨个说明，并给出必要的使用规范

The post 2015年7月架构师培训笔记 appeared first on 绿色记忆.

反应器模式（Reactor pattern）是一种事件处理模式，用于处理从一个或多个输入并发的发送给单个服务处理器（service handler）的请求。服务处理器对请求进行多路分用（demultiplexes） —— 解析并分发（dispatcher）给请求处理器（service handler）。

反应器模式通常是单线程的，但是它可以在多线程系统中运行。

能够为系统提供输入，或者消费系统的输出。

即Synchronous Event Demultiplexer，负责运行事件循环， 在所有资源上阻塞。当可以在资源上执行异步操作时，此分离器将资源转给分发器（dispatcher）。

能够注册、解除注册请求处理器，分发来自Demultiplexer的资源给相应的请求处理器。

处理特定类型的资源。

libevent是一个事件驱动编程库，可以在文件描述符上发生特定事件、超时后，执行相应的回调函数。回调函数还可以由信号、定时器触发。

The post 反应器模式 appeared first on 绿色记忆.

架构是一个过程，它定义了满足软件所有操作性、技术性需求的结构化的解决方案。同时对各种质量属性进行优化。

Philippe Kruchten（RUP主管）等人认为，架构是关于软件系统如何组织的一系列重大决定，包括：

1. 结构元素的识别选择以及它们的对外接口
2. 行为元素的识别，即上述结构元素之间的协作行为
3. 上述结构元素、行为元素如何有机结合成为子系统

Philippe Kruchten也认可架构牵涉到易用性、健壮性、性能、可重用性等非功能因素。同时需要兼顾技术性约束和权衡以及美学方面的考虑。

企业应用架构模式的作者Martin Fowler总结了当解释何为软件架构时，会反复出现的论点：

1. 架构将系统进行高层分解，形成多个协作的子系统或者模块
2. 这种分解决策一旦落地实施，就难以再改变
3. 一个大型系统中会有多个架构
4. 在系统的生命周期中，架构可能随着时间而改变，甚至发生重构
5. 架构可以归结为：软件设计中任何重要的东西

尽管有不同的描述方式，软件架构一定牵涉到以下内容：

1. 系统的结构或者叫组织——将个系统分解为多个组件，分解的粒度不会过细。根据系统的规模不同，可能分解到子系统或者模块级别
2. 明确分解后系统组件的交互机制
3. 明确对各种质量需求如何支持，这通常需要引入中间件、框架

用户接口风格设计（例如交互风格、主题和配色）通常不属于系统架构师的职责，但我认为用户接口风格应当在架构阶段即落地。

在决定软件架构时，需要考虑：

1. 用户如何与软件交互
2. 软件如何在生产环境下部署和管理
3. 软件的运行期质量属性，例如性能、并发性、安全性、健壮性、可扩容性、高可用性、易用性
4. 在软件的生命周期内，开发期质量属性，例如可互操作性、可扩展性、可重用性、可维护性如何保证
5. 架构的最根本的部分是什么，或者说，哪些决定如果出错后果最严重
6. 架构的最易变的部分是什么，或者说，哪些决定可以延迟决定
7. 你做了哪些关键的假设，如何验证这些假设。不要过度设计
8. 什么情况下，可能导致架构重构

架构的目标：

1. 暴露系统结构的同时，隐藏实现细节
2. 实现所有需求用例和应用场景
3. 满足不同干系人的需求
4. 同时满足功能需求、质量需求

为什么要做架构？其根本原因是为了降低复杂性，否则用机器语言可以编写出任何软件。

和其它任何工程一样，软件工程必须具有坚实的基础。对关键场景的错误考虑，对公共模块的错误设计，缺乏对关键决策的长远后果的考虑，都可能对软件工程带来严重的后果。例如：

1. 软件不能稳定运行
2. 不能支持现有或者未来的需求
3. 难以在生产环境下部署和管理

引入中间件、框架，可以减轻构建软件的工作量，但是不能用来代替针对特定应用场景和需求的架构。架构不是一堆框架的糅合。

框架是一种可重用的半成品软件，既然是软件，框架当然可以有自己的架构设计。

框架提供一般性的软件功能，这些功能可以被选择性的覆盖或者扩展，以产生针对性的软件。

框架用于辅助架构的落地，主要用于实现质量需求。在软件实现阶段，框架成为软件的一部分。

架构关注软件中的主要元素和组件如何交互（如何被其它组件或者用户使用）。每个组件的数据结构、算法或者实现细节是详细设计阶段需要考虑的。架构和详设常常重叠。某些情况下，详设具有天然的架构性特征，另外一些情况下，某些重大决策是细致到详设的。

前面我们提到过，软件架构（作为名词时）通常被描述为系统的结构或者组织。所谓系统，是完成一个或者多个功能的组件的集合。也就是说，架构需要决定如何来组织组件以满足功能。组件常常基于关注域（areas of concern）进行分组，例如下面的架构图，组件被划分到多个关注域：

分层是解决软件复杂性问题的重要法宝，在上图的例子中，多个关注域构成一个逻辑层，多个逻辑层堆叠形成系统的整体逻辑架构，跨层之间通常不会有交互。

很多设计原则从实际软件工程的经验教训中总结得到，这些原则不仅仅适用于架构，也适用于详设：

1. 关注点分离原则：尽可能的把软件划分为多个相互尽可能没有重叠的特性。重要的估量因子是，最小化交互点以实现高内聚低耦合
2. 单一职责原则：每个组件/模块应当仅仅负责一个特性/功能，或者一个聚合性的功能
3. 最少知识原则：也叫迪米特法则。一个组件应该尽可能少的知道其它组件的内部细节
4. 不要重复自己（DRY）：一个特定的特性/功能应该仅仅在一个组件中实现，不应在其它组件中重复
5. 尽可能使用组合而非继承
6. 不要过度设计：仅仅设计需要的功能。进行前瞻性设计时一定要考虑成本和失败的后果

1. 在每个层内，保持设计模式的一致性
2. 不要在应用程序里面重复实现一个功能
3. 创建编码风格和命名规范

1.  将关注域分离到层，应用关注点分离原则。主要好处有：
   1. 一个特性/功能可以独立的被优化
   2. 如果一个特性开发失败，可以被替换而不影响其它特性
   3. 让代码更加容易理解
2. 明确不同层之间如何交互。通常下层不会依赖上层，不得出现跨层依赖
3. 基于抽象达到层间松耦合的目标。抽象类、接口、Facade模式都是可用的工具
4. 不要把不同类型的组件混到一个层中
5. 在层或组件内保持数据格式的一致性

1. 组件或对象不应依赖其它组件或对象的内部细节，应用最少知识原则
2. 不要让组件的功能过载，应用单一职责原则。例如UI组件不应该包含数据库访问代码
3. 理解组件之间的交互方式。要结合部署方式确定，两个组件在进程内、跨进程还是跨机器部署
4. 尽可能的把横切性的功能从商业逻辑中抽象出去，越远越好。横切性的功能包括身份验证和授权、通信、缓存、日志等
5. 为组件定义一份清晰的接口规约

基本的应用程序类型包括：

1. 为移动设备设计的应用
2. 富客户端应用，安装并在客户端PC运行
3. 富因特网应用，具有丰富的UI组件
4. 服务型应用，用于支持松耦合的组件的交互

决定你的应用程序如何部署。各组件是否需要支持跨进程部署，是否需要支持部署在不同的服务器上，这些服务器是否具有网络协议限制、防火墙、路由限制。

部署策略对架构的影响很大，因为需要进程内组件交互可以直接进行函数调用，进程外组件交互必须使用IPC或者Socket等机制。

最近十多年各领域开源框架大放异彩，因此首先考虑选型开源框架，无法满足需求的情况下才考虑自研。

引入框架后，你的应用程序往往和它产生某种程度上的耦合，因此框架的选择需要慎重。使用框架时，应当尽量避免产生耦合，特别是明确的API调用。

质量属性聚焦于架构设计需要解决的一系列非功能性的关键问题。根据需求的不同，你需要关注的质量属性也不同。通常每个应用程序都需要关注安全性和性能，但是很多应用程序不需要关注互操作性和可扩容性。

横切关注域是不仅仅和某个特定分层有关的关注域。关键的横切关注域包括：

1. 系统日志：记录系统中各种事件，但不引入敏感信息
2. 身份验证：决定如何对用户、外部系统的身份进行验证。如何在各层之间传递其身份信息
3. 访问授权：决定每个层的每个组件能否被指定的实体访问
4. 异常管理：避免异常信息暴露到最终用户
5. 通信机制：选择适当的通信协议，最小化网络调用，保证数据安全
6. 缓存管理：识别哪些数据应该被缓存，在哪里缓存

所谓架构风格（Architectural Style，也叫架构模式），是一系列可重用的设计原则， 这些原则以组粒度Pattern的形式定义了一大类系统的抽象框架。你可以认为架构风格是一系列确定了应用系统“形状”的设计原则。

架构风格不会牵涉到具体的技术，因此可以用在技术不可知的技术讨论中。

架构风格可以根据它们的关注域的不同进行分类：

一个软件系统几乎不可能仅仅使用一种架构风格。例如，你可能使用SOA架构风格构建服务，同时使用分层架构和面向对象架构。

在开发面向Web的应用系统时，联用架构风格很有意义。使用分层架构风格可以帮助你实现关注点分离，将展现层逻辑和商业逻辑、数据访问逻辑分开。由于组织机构的安全性需求，你可能需要基于3-Tier或者N-Tier架构风格，将展现层部署在周界网络（内外网之间）中。在展现层内部，你可能进一步的应用分层架构风格，典型的是MVC模式。你也可能应用SOA架构风格，让展现层和应用服务器基于消息进行通信。

当构建一个桌面应用时，你可能需要让客户端向某个服务器程序发送请求，这需要C/S架构风格。在服务器端，你可能采用基于组件的架构，将服务器端应用分解为相互独立的组件，让这些组件暴露适当的通信接口。在实现组件时，使用面向对象架构风格可以改善可重用性、易测试性、灵活性。

很多因素会影响架构风格的选择，这些因素包括你的团队开发、设计能力，以及基础设施、组织方面的约束。

这种架构风格描述一种分布式系统，该系统由独立运行的客户端应用和服务器应用组成，服务器和客户端通过网络连接。最简单的C/S架构中服务器和客户端直接通信，也被称为2-Tier架构。

典型的C/S架构客户端是流行在PC上的Native应用，当今浏览器（B/S）、移动设备都可能称为客户端的载体。

C/S架构风格的变体包括：

1. 高安全性：数据存储在服务器上，服务器的安全条件往往远好于客户端
2. 中心化数据访问：由于数据集中在服务器上，因此管理起来方便
3. 易于维护：可以实现客户端对服务器的信息的无感知，这样服务器移动、维修、升级会很方便

1. 服务器端组件倾向于耦合，导致难以扩展、扩容
2. 集中性的服务器可能存在单点故障，降低可靠性

为了克服典型C/S架构的缺点，可以引入N-Tier部署架构、负载均衡、HA等

当满足以下条件时，可以考虑C/S架构风格：

1. 你的应用是基于服务器的，且服务器需要支持多个客户端
2. 你需要创建通过浏览器访问的应用
3. 你需要开发服务供其它应用程序消费
4. 你希望集中化数据存储、备份、管理 

这种架构风格描述了一种系统设计和开发的手段，它关注如何把设计分解为独立的功能、逻辑组件，并且让这些组件暴露出良好定义的通信接口。通信接口的形式可以包含方法、事件、属性。基于组件的架构是面向对象设计原则的一种高层抽象。面向组件架构不关心组件之间的通信协议、共享状态等问题。

组件可能依赖于某种平台提供的环境才能运行，典型的平台包括组件对象模型（COM）、分布式组件模型（DCOM）、通用对象请求代理架构（CORBA）、企业JavaBean（EJB）等等。

依赖注入（DI）、服务定位（Service Locator）之类的设计模式可以用来管理组件之间的依赖，同时降低耦合度、提升可重用度。这类设计模式常常用于构建组合性（Composite）应用程序，以及用于实现跨应用的组件重用。

基于组件架构的组件设计原则包括：

1. 可重用性，组件应该可以在不同的场景、不同应用中重用。但是某些组件的确会针对特定项目的特定任务
2. 可替换性，组件应该很容易被其它类似的组件替换
3. 上下文无关，组件应该被设计以在不同的上下文中工作。注入状态数据之类的特殊信息应该被传入，而不是保存在组件内
4. 可扩展性，组件应当允许扩展，以产生新的行为
5. 封装性，组件暴露接口，其调用者基于接口使用其功能，不应该对外暴露任何内部状态和处理逻辑
6. 独立性，组件应该尽可能少的依赖其它组件，这样它才能部署到适当的运行环境中，同时不影响其它组件或系统

1. 用户接口类组件：按钮、表格，这些组件通常被称为控件（Controls）
2. 助手类组件/实用工具：暴露一些通用的，在其它组件中反复需要的功能
3. 资源密集型组件：占用资源大，应当以按需（JIT）方式创建。很多远程、分布式组件属于此类型
4. 排队组件（ Queued Components）：这些组件的接口可以通过消息队列机制，异步的调用

1. 易于部署：当一个新版本的兼容性组件开发完成后，你可以安全的替换老版本的组件，而不会对系统产生影响
2. 开发成本：使用成熟通用的第三方组件可以降低开发的时间成本
3. 易于开发：组件暴露良好定义的接口，协作开发时很容易通过Mock实现并行开发
4. 可重用性：组件往往能够跨越多个系统、项目重用
5. 降低技术复杂度：通过使用组件容器以及组件容器提供的服务，可以降低使用复杂度。组件容器的服务可以包括组件激活、生命周期管理、方法排队、事件机制、事务性

当满足以下条件时，可以考虑基于组件的架构风格：

1. 你已经拥有合适的组件，或者可以从第三方提供商获得这样的组件
2. 你的应用程序大量的执行过程式的功能，可能没有或者具有较少的数据输入
3. 你希望联用基于不同编程语言实现的组件
4. 你希望实现一个可拔插或者组合性的架构，希望随时能够替换某些组件

领域驱动设计（DDD）是一种面向对象的软件架构风格。它以业务领域（Business Domain）、业务领域的元素和行为以及这些元素行为之间的关系为基础和依据。

DDD以行业专家（而不是技术专家）的视角来识别、定义（领域）模型，并基于这些模型来组织软件系统，以实现领域的业务逻辑。

要应用DDD，你必须对需要建模的业务领域具有深刻的理解，或者善于获得这些领域的知识。开发团队通常需要和行业专家协同工作。架构师、开发人员、行业专家通常具有不同的知识背景，在很多上下文中他们使用不同的语言描述自己的目标、设计、需求。使用DDD时，所有这些人员使用一种语言来交互，这种语言面向业务领域，不使用技术行话。

基于DDD设计的软件的核心是领域模型，这些模型是上述公共领域语言的直接映射。通过分析公共语言，团队能够快速的发现软件中的Gap。创建公共领域语言不是简单的接受并应用行业专家的知识。开发团队内部的沟通问题不仅仅由于对领域语言的错误理解，也常常由于领域语言本身具有歧义性。DDD过程不仅仅需要创建公共领域语言，更要改善、优化领域语言。这种优化转而能够软件开发收益，因为模型即领域语言的直接映射。

1. 沟通：开发团队的所有成员使用领域模型及其定义的实体来针对业务知识进行交流。使用的语言是公共的业务领域语言，而不是技术行话
2. 可扩展性：领域模型通常是模块化、灵活的。当需求变化后，扩展它们将比较容易
3. 可测试性：领域模型的对象松耦合、高内聚，这意味着它们便于被测试

当满足以下条件时，可以考虑DDD：

1. 业务领域很复杂，需要有效改善团队的沟通
2. 你需要基于某种公共语言来向干系人解释你的设计
3. 你拥有大量复杂的企业级数据场景，难以通过其它技术手段管理它们

最简单的屏蔽复杂性的途径是引入新的层。

分层架构风格将软件系统中具有相关性的功能分组到一个独立的层中。这些层逐个堆叠，形成类似于栈的结构。每个层内部的功能具有相近的角色或职责。层与层之间的交互是明确定义的、松散耦合的。对应用程序进行分层可以实现关注点的强分离，从而实现灵活性、可维护性。

分层架构风格被描述为倒金字塔式重用。原因是每个层都对它的直接下层的职责和抽象进行了某种聚合。在严格的分层架构中，每个层仅仅能和本层内、直接下层内的组件进行交互。比较自由的分层架构则允许和非直接下层中的组件进行交互。

应用程序的各分层，可能部署在单个服务器中（相同Tier），也可能部署在多台服务器中（N-Tier）。

1. 抽象：分层架构抽象出系统的视图，同时提供足够的细节，让团队能够理解每个层的职责和角色，以及层与层之间的关系
2. 封装：由于数据类型、方法、属性、实现细节不会在层边界暴露出去，因此在设计时不需要对它们做任何假设
3. 清晰的层：每个层的功能应当很明确，上层可能向下层发起调用，也可能响应下层发布的事件，这允许上下层之间的数据流动
4. 高内聚：应当明确每个层的职责边界，确保每个层仅仅包含和它的任务直接相关的功能
5. 可重用：下层不能对上层产生依赖，这有利于下层的重用
6. 低耦合：层与层之间的交互应当基于抽象和事件，以降低耦合

消息总线架构风格描述了使用一类中间件系统的原则。这类中间件能够基于多种信道接收、发送消息。这样，以这类中间件作为交互中介的应用程序不需要知道彼此的细节，例如部署位置、使用的通信协议。

最常见的消息总线架构的实现通常基于消息路由器或者订阅/发布系统，通常需要使用到某种消息队列软件。消息总线提供的功能包括：

1. 面向消息的通信，所有应用以模式（Schema，结构）已知的消息进行通信
2. 复杂处理逻辑，复杂的操作可以通过一组较小的操作联合而成，每个操作负责特定的任务
3. 集成不同的环境，基于消息和通用的标准，你可以集成基于不同开发语言的应用，例如Java和.NET

消息总线架构在很多年依赖都用于支持复杂的逻辑处理，它提供了一种可拔插的架构，你可以随时将应用接入到总线以提供新的功能，或者接入统一应用的多个实例以扩容。

消息总线架构的变体包括：

1. 企业服务总线（ESB）：总线和应用以服务的方式进行通信。ESB常常提供消息格式转换的功能，这样使用不兼容消息格式的应用可以通过总线进行互操作
2. 因特网服务总线（ISB）：类似于ESB，但是应用程序在云端而非企业内部网络部署。ISB的核心理念是基于URI的资源定位和消息路由控制策略

1. 可扩展性：应用程序可以被添加、移除，现有接入的应用程序不受影响
2. 低复杂性：每个应用程序仅仅需要和总线直接交互
3. 灵活性：实现复杂流程的应用程序集、应用程序之间的交互方式，可以根据业务需求轻松的调整。通常只需要调整配置或路由参数
4. 低耦合：应用程序仅仅暴露了和总线交互的接口，应用程序本身不会相互依赖
5. 可扩容性：应用程序的多个实例可以连接到总线，以提供更大的处理能力
6. 简单性：尽管总线本身引入了复杂度，但是对于每个应用程序而言，它仅仅需要和一个总线交互，而不是很多应用程序

当满足以下条件时，考虑使用基于总线的架构：

1. 既有应用程序需要交互以完成特定任务
2. 需要将多个任务合并为单个操作

N-Tier是一种部署架构风格，它类似于分层架构，描述了功能的分离方式。被分离的功能可能部署在不同的物理服务器上。这些功能通常使用面向组件的风格设计，使用平台特定的通信手段而非基于消息通信。

典型的N-Tier架构至少具有三个层。例如一个注重安全的Web财务系统，它的业务逻辑层必须部署在防火墙之后，而其展现层则必须部署在周界网络中暴露HTTP端口，客户端则可能运行在因特网上。

1. 可维护性：由于每个Tier相互独立，系统升级不会影响到其它Tier
2. 可扩容性：可以为某个Tier添加更多的实例实现扩容
3. 灵活性：每个层可以独立的管理和扩容，因而提高了灵活性
4. 高可用性：某个Tier可以部署Master/Slave方式的实例，实现HA

这种设计风格将应用程序或者系统划分为单独的可重用、自包含的对象，每个对象包含相关的数据和行为。面向对象的设计将系统看做一系列相互协作的对象，而非一系列例程、过程指令。对象是离散的、独立的、松耦合的，它们通过接口通信。

1. 抽象：简化复杂操作为一般化形式，暴露其基本特征
2. 组合：对象可以相互组装，形成更大的对象。大对象可以隐藏其包含的对象或者为包含对象提供接口
3. 继承：对象可以从其它对象集成，从而直接获得它的特性
4. 封装：对象仅仅包含必要的方法、属性、事件，而隐藏大部分细节
5. 多态：允许在子类中覆盖某些行为
6. 解耦：通过定义抽象类、接口，使用者可以和对象解耦

SOA风格基于一系列服务对外暴露应用程序的功能，其它的应用程序可以调用这些服务。服务是松散耦合的，因为它们使用基于标准的接口，这些接口可以被调用、发布、发现。SOA中的服务必须以基于消息的、格式（Schema）明确的暴露接口，这些接口是面向应用级别而非面向组件的，具有更粗的粒度。

1. 服务应该是自治的：所有服务应该独立的开发、维护、部署、版本化
2. 服务应该是分布式的：只要目标网络支持通信协议，服务可以部署在任何网络中，不管是本地还是远程
3. 服务应该是松耦合的：每个服务不对其它服务产生依赖，只要接口保持兼容，服务可以被替换
4. 服务共享Schema和规约，而不是类

1.  Domain alignment：重用基于标准接口的服务，可以增加商业和技术机会，降低成本
2. 抽象：服务基于规范化的合约暴露接口，因此了实现细节，因此具有松耦合、抽象性
3. 可发现：服务可以暴露描述性信息，让其它应用程序能够定位它并自动确定其接口
4. 互操作性：由于协议、数据格式基于开放工业标准，因此服务提供者、消费者可以基于不同平台开发和部署

在以下情况下，可以考虑使用SOA：

1. 需要重用某个服务
2. 准备从第三方提供商购买服务
3. 构建使用多个服务的单一UI应用
4. 准备构建SaaS平台或者其它基于云的应用
5. 必须使用平台无关的、基于消息的通信方式

使用一系列的微小服务来实现整体的业务流。每个微小服务通常具有专用的数据库、缓存。

每个微服务工作在独立的进程中，可以单独的扩容/缩容，其扩容的自由度比传统粗粒度的SOA更高。微服务常常基于容器技术部署。

每个微服务常常对应了一个全栈的团队，因此跨团队的沟通成本较低。

4+1架构视图模型由Philippe Kruchten提出，基于多种、并发的视角来描述软件密集型系统的架构。这些视角是站在不同干系人角度的，包括最终用户、开发人员、项目管理员。

该模型的4各视图是逻辑架构、开发架构、进程架构、物理架构。此外，典型用例或场景作为+1视图，主要用于架构。

也叫实现视图（Implementation View），它从程序员的视角来描述系统，项目管理需要关注此视图。可以考虑使用UML的组件图、包图来描述系统的组件及其关系。

从最终用户的角度来描述系统，着重阐述系统包含的功能。UML的类图、状态图可以用于描述逻辑架构。

也叫部署视图（Deployment View）。从系统工程师的角度来描述系统，关注软件组件的部署拓扑，以及组件之间的物理连接。UML的部署图可以用于描述物理架构。

关注系统的运行时动态行为，描述系统的进程如何交互。该视图处理并发性、分布性、性能、可扩容性等质量属性。UML的活动图可以用于描述进程架构。

通过一小部分关键的业务用例来阐述系统架构。场景视图描述对象、进程之间如何交互。

尽管用户体验设计通常不是系统架构设计师的职责范围，但用户体验设计的部分工作的确是“架构”级别的，用户体验设计对易用性、可查找性（Findability）、可访问性等质量属性有重要影响。

架构设计牵涉到四个目标：用户目标、业务目标、系统目标、开发目标的权衡。用户体验设计主要关注如何满足用户目标。

用户体验设计可能影响架构和设计决策，例如：

1. 为了更实时的UI信息更新，可能导致使用WebSocket作为通信方式
2. 为了获得更好的用户交互体验，可能需要设计特殊的控件
3. 为了提升可访问性，引入国际化支持，这需要架构考虑引入新的横切面

所谓用户体验，就是指你操作应用程序的UI时的内心感觉。

用户体验设计是通过改善产品的易用性、可访问性，以提高用户满意度的过程。

最终用户了解软件的唯一途径是和软件的用户接口进行交互，用户体验设计影响用户的第一印象。从心理学角度来说，第一印象非常重要，差劲的用户体验容易让用户对软件甚至是开发商产生刻板印象。
对于产品来说，试用时的用户体验很大程度上影响其采购意愿。

也叫图形设计，视觉设计通过色彩、图片、符号等视觉元素向用户传递信息。
视觉设计确定用户接口的美学特性 —— 外观和感觉（Look & Feel）。外观和感觉也即系统的主题（Theme），应当在架构阶段结合用户特点进行确定。

所谓信息架构，是指在产品或服务中正确的对信息进行结构化和组织，以提升易用性和可检索性。其工作内容包括：

1. 导航设计，选择用户接口元素的排列方式。其目标是让用户在信息架构浏览时更加轻松
2. 结构/组织/标签：
   1. 结构化：化简信息量到它的基本单元，并将这些基本单元关联到一起
   2. 组织：以有意义的方式来分组上述基本单元。例如表单、Grid的行
   3. 标签：使用适当的词汇来支持导航和查找
3. 查询设计：查询是信息架构中最关键的因素，需要让用户通过检索、询问、浏览等方式获取期望的信息

交互设计是用户体验设计的关键。交互设计需要关注的内容是：

1. 定义在某个上下文中最合适的交互模式
2. 在研究用户知识特点、使用习惯的过程中确定用户的交互需求
3. 理解哪些信息和特性对于用户最为重要
4. 确定用户接口的行为，例如拖拽、选取、鼠标悬停时的行为
5. 让用户接口尽可能的直观
6. 在整个系统中保持交互风格的一致性

在过去数年里，交互设计师的职责发生了很大的变化。曾经他们仅仅是确定UI控件及其布局，然后与开发工程师进行确认，现在，交互设计师具有更大的自由度，他们进行面向用户需求的概念性接口设计，而不是首先关心此用户接口能否被实现。

很明显，性能对用户体验影响很大。性能的三大指标：响应时间、吞吐量、持续高速性，其中响应时间的高低直接影响用户的等待时间。

提升系统的健壮性有利于增强用户体验。识别用户的某些输入错误并正确处理，甚至是更正，可以很好的提升用户满意度。反之，用户可能感到困惑，例如某些用户不理解全角、半角数字的区别，在输入全角数字时引发失败会让他不解。

增强此质量属性对传统架构设计的反馈：设计合理的用户输入处理横切面。

提升易用性很显然会增强用户体验。其方法包括：

1. 简单的用户接口，界面要尽量的简单，不要让人望而生畏
2. 缩短响应时间，不要让用户不耐烦的等待。如果等待不可避免，一定要给予合理的提示
3. 避免用户反感，过多的弹窗、移动应用中过多的推送、角标可能让用户厌烦
4. 简单清晰的导航，不管导航放在哪里，都要容易找到，易于理解
5. 理想的配色，符合视觉心理需求的主题和配色。适当的对比度，不要让用户看不清

增强此质量属性对传统架构设计的反馈：

1. 缩短响应时间，即要求提升性能这一质量属性

提升可访问性很显然会提升用户体验，没有此质量属性直接导致部分人群无法使用系统。

可访问性的提升主要牵涉两方面内容：

1. 国际化，用户支持不同语言背景的用户
2. 障碍人群支持，包括盲人、色盲、肢体残疾等用户

增强此属性对传统架构设计的反馈：

1. 要实现国际化，需要通盘考虑，使用消息占位符代替消息文本，可能需要在展现层引入新的子层
2. 要支持障碍人群，可能需要开发大量功能模块，例如TTS、语音识别 

The post 软件架构设计基础 appeared first on 绿色记忆.

这种设计模式引入一个强大的抽象层，此层对获得服务的过程进行封装。该模式使用一个名为服务定位器的注册中心来进行服务的定位发现，对服务器进行请求，可以获得使用某种服务的所有必要信息。

此模式中包含三个角色：客户端、服务定位器、服务。

此模式的优势：

1. 服务定位器可以作为简单的“运行时链接器”使用。组件可以在运行时加入到应用中，整个应用不需要重新编译，某些情况下甚至不需要重启应用
2. 服务定位器可以在运行时动态添加、替换、移除服务，例如替换掉一个XML解析器的实现
3. 应用和库可以完全隔离，它们仅仅通过服务定位器交互

此模式的缺点：

1. 服务定位器对于系统的其它部分是黑盒。服务定位器发生错误将难以检测和恢复，从而导致整个系统的可靠性下降
2. 服务定位器通常是单例的，这可能导致性能瓶颈
3. 服务定位器可能是一个安全风险点，因为它允许外部代码的注入
4. 服务定位器隐藏了它的类依赖，某些本应该在编译器暴露的错误以运行时错误的形式出现
5. 增加了测试的难度，因为所有测试用例都需要和服务定位器交互，才能获得一个服务的Mock

Java命名和目录服务可以认为是服务定位器模式的实现。此服务就相当于一个定位器，它提供了发布、获取服务的接口。

ZooKeeper可以作为服务定位器使用，但这是一种变体：

1. 定位器不是单例的，ZooKeeper通常是集群部属，避免了单点故障
2. ZooKeeper都用于分布式架构中，所谓服务也需要远程调用，而不是进程内基于内存地址的直接调用

The post 服务定位器模式 appeared first on 绿色记忆.

1. AspectJ编译器能识别任何普通的Java代码，可以使用ajc编译.java文件
2. 织入方式：
   

   源代码织入	织入器作为编译器的一部分，处理源代码，支持经典语法和注解语法。生成的字节码符合JVM规范，需要使用ajc代替javac
   字节码织入	传递给织入器的是字节码。使用这种方式时，包含编译普通Java类、编译切面，织入3个步骤。
   加载时织入	传递给织入器的是Java类字节码、切面类，以及aop.xml配置文件。

3. AspectJ暴露的连接点。只能在这些连接点上应用通知：
   

   	暴露的连接点	代码表现
   方法	执行 Execution	方法体：该连接点环绕整个方法体的执行过程。这也是Spring AOP唯一支持的接入点类型。通知被织入方法体 切入点语法：execution(方法签名)
   	调用 Call	方法调用：该接入点发生在方法被调用时。通知被织入调用者代码处 切入点语法：call(方法签名)
   构造器	执行 Execution	对象构造逻辑：该连接点环绕整个构造器的执行过程 切入点语法：execution(构造器签名)
   	调用 Call	对象构造调用 切入点语法：call(构造器签名)
   字段访问	读访问 Read access	读取类或对象的字段 切入点语法：get(字段签名)
   	写访问 Read access	写入类或对象的字段 切入点语法：set(字段签名)
   异常处理	处理器 Handler	处理异常的catch块 切入点语法：handler(类型签名)
   初始化	类初始化 Class initialization	类加载，包括静态成员初始化部分 切入点语法：staticinitialization(类型签名)
   	对象初始化 Object initialization	在构造器中的对象初始化。包含：从一个父构造器返回，到当前构造器执行完成的部分（不包括调用父构造器的部分） 切入点语法：initialization(构造器签名) Spring的@Configurable即为此例 。下面的例子解释了连接点的范围： public class SavingsAccount extends Account { private boolean isOverdraft; private int minimumBalance; //构造器1 public SavingsAccount( int accountNumber, boolean isOverdraft ) { super( accountNumber ); //对象初始化连接点：构造器1，2 this.isOverdraft = isOverdraft; } //构造器2 public SavingsAccount( int accountNumber ) { //对象初始化连接点：构造器2 this( accountNumber, false ); //对象初始化连接点：构造器2 this.minimumBalance = 25; } }
   	对象预初始化 pre-initialization	在构造器中的对象初始化之前：用的很少，从当前构造器调用，到父构造器调用结束为止 切入点语法：preinitialization(构造器签名)
   通知	执行 Execution	通知的执行：环绕某个通知的整个执行。可以对通知进行通知 切入点语法：adviceexecution()

4. AspectJ切入点声明语法
   

   /**
    * 切入点声明语法，包含5个部分：
    * 访问标识符：例如 public
    * 关键字：pointcut
    * 切入点名称()
    * 切入点类型：例如execution、call，参考：第3点
    * 切入点签名：根据切入点类型不同，可能是类型签名、方法签名、字段签名
    */
   public pointcut secureAccess(): execution(* MessageCommunicator.deliver(..));

   AspectJ支持仅有切入点名称，而没有类型和签名的切入点，通常使用在抽象切面中。
   AspectJ支持匿名切入点，作为通知签名的一部分存在。
   AspectJ支持使用 !、 && 、|| 来作为切入点的运算符

5. AspectJ通知定义语法：由通知声明、切入点定义、通知体三部分组成
   

   组成	说明
   整体语法形式： [@AdviceName("通知的名称")] [返回值] 通知类型([上下文信息]) [returning|throwing] [throws 通知抛出的异常] : 切入点定义([上下文信息]) { 通知体 }
   通知声明	通知类型可以是：before, after 或 around，其中around需要声明返回值通知声明可以指定通知体可用的上下文信息，包括：执行对象通知声明可以指定通知体可能抛出的异常
   切入点定义	位于冒号之后，任何匹配切入点定义的连接点上都会执行本通知
   通知体	可以访问一系列特殊的变量或关键字，例如：proceed、thisJoinPoint、thisJoinPointStaticPart、 thisEnclosingJoinPointStaticPart

6. AspectJ支持的通知类型
   

   通知类型	说明
   Before advice	在连接点执行之前执行，如果抛出异常，那么连接点不被执行
   After advice	在连接点执行之后执行，根据连接点的执行结果，具有3个子类型：After (finally)：在连接点执行之后执行，不论其结果，通知声明语法：after()After returning：在连接点执行成功后执行，通知声明语法：after() returning(<ReturnType returnObject>)After throwing：在连接点执行失败后执行，通知声明语法：after() throwing(<ExceptionType exceptionObject>)
   Around advice	环绕连接点的执行过程，具有修改连接点执行上下文的能力，可以用来： 在连接点之前/之后添加额外的逻辑，例如性能分析 跳过原先逻辑还执行备选的逻辑，例如缓存。只要不调用proceed()，即跳过 使用try-catch包裹原先逻辑，提供异常处理策略，例如事务管理

通配符用于匹配一系列的连接点。

这里的类型泛指：类、接口、注解、切面、基本类型
基本类型签名示例：

基于注解的类型签名示例：
由于Java不支持注解的继承，所有注解名后不会出现加号。注意注解必须运行时可见（

RetentionPolicy.RUNTIME

基于泛型的类型签名示例：

联合类型签名示例：

构造器签名与方法类似，但是：

1. 由于构造器没有返回值，因此不得在签名中指定返回值
2. 由于构造器不能为静态，故不得添加static关键字
3. 由于构造器没有名称，必须使用new作为其名称部分

基本方法签名示例：

基于注解的方法签名示例：

注意注解必须运行时可见（

RetentionPolicy.RUNTIME

字段签名中，使用get表示读字段，set表示写字段：

字段签名示例：

注意注解必须运行时可见（

RetentionPolicy.RUNTIME

AspectJ提供几种切入点指示器（designators），配合上面所述的切入点签名，即组成切入点。
切入点通过两种方式与连接点进行匹配：

1. 类型限定的切入点：直接映射到某个类型的连接点，参考AspectJ暴露的连接点一节中的“切入点语法”部分
2. 无类型的切入点：根据指定的信息，来选择特定的连接点。这些信息可以是：连接点上下文的运行时类型、控制流，或者此法作用域（lexical scope）

匹配：指定类型和签名的连接点
Spring：仅支持execution类型
静态确定：是

不去限定连接点的类型，还是通过若干种规则去匹配多种连接点。

Spring虽然仅仅支持execution一种类型的连接点，但是却支持多种方式来选择它们

基于控制流的切入点
这一类的切入点匹配 处于其他切入点的控制流之中 的连接点。这句话比较难以理解，以贷款业务为例，假设Account.debit()方法调用Account.getBalance()进行余额查询，那么，可以说：getBalance在debit的控制流之中。类似的，字段访问、异常处理，也可以处于某个切入点的控制流之中。
Spring不支持这一类切入点，不能静态确定（需要运行时判断）
包含两种切入点类型：cflow、cflowbelow，后者不包括启动控制流的连接点本身

下面以事务管理的场景为例，来说明控制流切入点的用法：

package cc.gmem.aj.cflow;
public class Account
{
    //两个方法均具有事务注解，但是，我们需要在“最外层”来启动事务
    //需要忽略内层的事务注解
    @Transactional
    public void debit()
    {
        getBalance();
    }
    @Transactional
    public void getBalance()
    {
    }
}

public aspect TransactionAspect
{
    //匹配所有标注了@Transactional的方法执行
    private pointcut transacted() : execution(@Transactional * *(..));
    //匹配这样的@Transactional方法：不在@Transactional方法的所确定的控制流的内部
    private pointcut topLevelTransacted() : transacted() && !cflowbelow(transacted());

    Object around() : topLevelTransacted() {
        System.out.println( "启动事务" );
        Object ret = proceed();
        System.out.println( "结束事务" );
        return ret;
    }
}

基于词法结构的切入点
匹配：在指定类型、方法、构造器内的连接点
Spring：支持within()，不支持withincode()
可以静态确定
包含两种切入点类型：within(类型签名)、withincode(构造器签名|方法签名)

执行对象切入点
根据运行时对象类型来选择连接点。并且，可以收集执行对象——双重功能。

包含两种类型：this(<Type or ObjectIdentifier>)、target(<Type or ObjectIdentifier>)，前者匹配this引用为指定类型的连接点；后者匹配方法调用target为指定类型的连接点。

该类切入点不支持类型通配，也不支持泛型。该类切入点不会匹配任何静态方法的执行连接点。

注意区别：
execution(* Account.*(..)) 匹配Account类的任何静态、成员方法
execution(* *.*(..))  && this(Account)：匹配Account及其子类的任何成员方法
参数切入点
该类切入点根据连接点的参数对象的运行时类型来匹配。并且，可以收集匹配的参数对象。
Spring支持此类切入点。无法静态确定。
所谓参数对象，根据连接点不同，含义也不同：

1. 对于方法、构造器连接点，参数对象即方法参数
2. 对于异常处理连接点，参数对象即被处理的异常
3. 对于字段写入连接点，参数对象即被写入的值

该类切入点的形式为：args(Type or ObjectIdentifier, ..)

基于注解的切入点

注意：注解本身被标注的注解影响AOP行为：

1. @Retention(RetentionPolicy.RUNTIME)：只有设置为运行时保留，才能在运行时进行匹配性判断
2. @Inherited：只有标注了此注解，子编程元素（类、方法）才能继承父元素上标注的注解

AspectJ支持根据类型、方法、字段所标注的注解来匹配连接点

条件检查切入点
此类切入点在连接点上的一些条件检查。通常和其它切入点联合使用

本段代码示意经典的AspectJ语法：

package cc.gmem.aj;

//切面的声明
public aspect SecurityAspect
{

    private Authenticator auth = new Authenticator();

    //切入点的声明
    pointcut secureAccess(): execution(* MessageCommunicator.deliver(..));
    //通知声明：针对secureAccess切入点的before通知
    before() : secureAccess() {
        System.out.println( "Checking and authenticating user" );
        auth.doAuthenticate();
    }
}

本段代码示意基于注解的AspectJ语法：
基于注解的语法，可以作为普通Java类编译，并且使用LTW（加载时织入）机制，在类被加载到JVM中时进行织入。

package cc.gmem.aj;

import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Before;
import org.aspectj.lang.annotation.Pointcut;

@Aspect
public class SecurityAspect
{

    private Authenticator auth = new Authenticator();

    @Pointcut ( "execution(* cc.gmem.aj.MessageCommunicator.deliver(..))" )
    public void secureAccess()
    {
    }

    @Before ( "secureAccess()" )
    public void secure()
    {
        System.out.println( "Checking and authenticating user" );
        auth .doAuthenticate();
    }
}

环绕通知的简单例子，注意proceed()的使用：

public aspect SecurityAspect
{
    private Authenticator auth = new Authenticator();

    pointcut secureAccess(): execution(* MessageCommunicator.deliver(..));

    Object around() : secureAccess() {
        long start = System.nanoTime();
        //伪关键字proceed，用于继续执行被通知的目标方法
        Object ret = proceed();
        //thisJoinPointStaticPart是通知可用变量之一，可以获取连接点的静态信息，例如方法名
        System.out.println( thisJoinPointStaticPart.getSignature() + " took " + ( end - start ) + " nanoseconds" );
        return ret;
    }
}

上下文收集的简单例子：

package cc.gmem.aj;

import java.sql.Connection;
import java.sql.SQLException;

public aspect ConnectionAspect
{
    //匹配Connection的任何抛出SQLException方法的调用
    //被调用（target）的Connection对象收集为connection变量。
    pointcut connectionOperation( Connection connection )//独立定义的切入点，必须使用这种参数声明来传递上下文信息给通知
        : call(* Connection.*(..) throws SQLException) && target(connection);

    Object around( Connection connection ) : connectionOperation(connection) {//传递了上下文
        long startTime = System.nanoTime();
        Object ret = proceed();
        //thisJoinPoint是通知体可用的变量之一
        System.out.println( "Operation " + thisJoinPoint + " on " + connection + " took " + ( System.nanoTime() - startTime ) );
        return ret;
    }
}

上下文收集注解的例子：

before(Secured secured ) : 
    //匹配任何方法执行
    execution(* *(..)) 
    //匹配连接点目标————即方法本身————上具有@secured注解的连接点
    && @annotation(secured)
{
    //注解可以像普通对象一样被使用
    checkPermission(secured.permission());
}

上下文收集的另外一个例子，注意传递给目标的参数被收集，可被通知体使用：

package cc.gmem.aj;

public aspect AccountAspect
{

    boolean processOverdraft( Account account, float amount )
    {
        return true;
    }

    void around( Account account, float amount ) throws InsufficientBalanceException
    //匹配任何对Account.debit(float) throws InsufficientBalanceException方法的调用
        : call(void Account.debit(float) throws InsufficientBalanceException)
        && target(account) && args(amount)//收集的上下文信息作为局部变量使用
    {
        try
        {
            proceed( account, amount );//传递给目标方法的参数，可以任意修改
        }
        catch ( InsufficientBalanceException ex )
        {
            //进行透支处理
            if ( !processOverdraft( account, amount ) )
            {
                throw ex;
            }
        }
    }
}

在classpath的META-INF/aop.xml中，声明需要织入的切面：

<aspectj>
    <aspects>
        <aspect name="cc.gmem.aj.SecurityAspect"/>
    </aspects>
</aspectj>

通过指定JVM启动参数-javaagent来启用LTW：

-javaagent:%ASPECTJ_HOME%\lib\aspectjweaver.jar

如果使用Spring，可以通过配置，避免修改JVM启动参数

AspectJ支持连接点、切入点、切面等构造。

AspectJ的动态横切构造依赖于“通知”实现。通知包括Before、After、Around几种。

收集连接点上下文

连接点上下文包括两种类型：

通过反射访问连接点上下文

作为备选方式，AspectJ提供了基于反射机制的访问静态（不会随着连接点执行而变化的）、动态连接点上下文信息的方法。这种方式可以完全替换上一条进行动态上下文收集，但是具有以下缺点：

1. 性能较为低下
2. 缺少静态语法检查
3. 比较笨重

通过AspectJ提供的通知体可用的特殊变量来使用这种反射API：

两种访问连接点上下文的方式的对照表

静态横切总是在动态横切之前应用。

静态横切构造由：跨类型声明（inter-type declaration ，ITD，亦称“引入introduction)”）和织入时声明（weave-time declarations）组成
跨类型声明（引入）
可以修改类、接口、或者切面的静态结构，例如增加一个字段，添加一个接口。在一个切面中，声明其他类型的结构，故曰ITD。下面是一个例子：

package cc.gmem.aj;

public aspect TrackingAspect
{

    //声明MessageCommunicator实现接口AccessTracked，效果和Java标准语法一样
    declare      parents: MessageCommunicator implements AccessTracked;

    //声明AccessTracked类型的一个字段，所有它的子类型自动获取此字段
    private long AccessTracked.lastAccessedTime;

    //声明AccessTracked类型的两个方法，所有它的子类型自动继承这些方法
    public void AccessTracked.updateLastAccessedTime()
    {
        lastAccessedTime = System.currentTimeMillis();
    }

    public long AccessTracked.getLastAccessedTime()
    {
        return lastAccessedTime;
    }

    before( AccessTracked accessTracked ) : //声明了一个通知局部变量accessTracked
        execution(* AccessTracked+.*(..)) //AccessTracked子类型的任何方法
        && !execution(* AccessTracked.*(..))//除了AccessTracked本身的方法
        && this(accessTracked)//this对象收集为accessTracked变量
    {
        accessTracked.updateLastAccessedTime();
    }

    private static interface AccessTracked
    {
    }
}

成员引入的规则

1. 只能引入private、public成员，前者只能被切面类访问，后者可以被系统中所有类访问
2. 如果是private的，多个切面可以引入同名的成员
3. 切面可以引入字段、函数、构造器到类或者接口。特别的，可以引入方法的实现到接口——缺省实现
4. 如果切面引入一个和类中同名的方法，那么，类中的那个方法被保留
5. 成员引入只能针对一个类型

接口缺省实现的例子

package cc.gmem.aj;

public interface Nameable
{
    public void setName( String name );

    public String getName();
    //缺省实现
    static aspect Impl
    {
        private String Nameable.name;

        public void Nameable.setName( String name )
        {
            this.name = name;
        }

        public String Nameable.getName()
        {
            return this.name;
        }
    }
}

使用ITD来实现Java的Mixin机制

Mixin是一种程序构造，允许在已有类中混入特定的逻辑，Java语言没有语言级别的机制，下面的例子示意了如何使用AspectJ进行混入

//一个标记性接口，用于混入功能
public interface BeanSupport {}
//一个简单的POJO，需要混入：属性变更监听的功能
public class Customer implements BeanSupport
{
    private String address;
    public String getAddress()
    {
        return address;
    }
    public void setAddress( String address )
    {
        this.address = address;
    }
}

通过下面的代码，即可为Customer或者任何实现了BeanSupport的类型混入属性变更的功能，而没有任何的侵入性。

public aspect BeanMakerAspect
{

    private PropertyChangeSupport BeanSupport.propertyChangeSupport;
    public void BeanSupport.addPropertyChangeListener( PropertyChangeListener listener )
    {
        propertyChangeSupport.addPropertyChangeListener( listener );
    }
    public void BeanSupport.removePropertyChangeListener( PropertyChangeListener listener )
    {
        propertyChangeSupport.removePropertyChangeListener( listener );
    }
    pointcut beanCreation( BeanSupport bean )
    //匹配BeanSupport及其子类型的初始化连接点
    : initialization(BeanSupport+.new(..)) && this(bean);

    pointcut beanPropertyChange( BeanSupport bean, Object newValue )
    //匹配BeanSupport及其子类型的任何Setter方法的执行
    : execution(void BeanSupport+.set*(*))
    && args(newValue) && this(bean);
    //BeanSupport初始化成功后，创建一个propertyChangeSupport字段的实例
    after( BeanSupport bean ) returning : beanCreation(bean) {
        bean.propertyChangeSupport = new PropertyChangeSupport( bean );
    }
    //Setter调用后，发布相应的事件
    void around( BeanSupport bean, Object newValue )  : beanPropertyChange(bean, newValue) 
    {
        String methodName = thisJoinPointStaticPart.getSignature().getName();
        String propertyName = Introspector.decapitalize( methodName.substring( 3 ) );
        Object oldValue = getPropertyValue( bean, propertyName );
        proceed( bean, newValue );
        bean.propertyChangeSupport.firePropertyChange( propertyName, oldValue, newValue );
    }
}

修改类层次结构

AspectJ提供两种需要类层次的形式：

declare parents : [TypePattern] implements [InterfaceList];
declare parents : [TypePattern] extends [Class or InterfaceList];
//举例：所有实体类实现BeanSupport接口
public aspect EntityBeanParticipationAspect {
    declare parents: @Entity * implements BeanSupport;
}
//hasMethod、hasField，任何包含指定模式方法或者字段的类：
declare parents: hasmethod(@Observed * *(*)) implements BeanSupport;

引入注解

AspectJ支持为字段、类、方法等添加注解

简化异常处理

允许不强制捕获受查异常，声明方式如下：

//这里声明不需要强制捕获的异常
declare soft : <ExceptionTypePattern> : <pointcut>;

织入时声明——警告或者错误信息

可以在织入时，根据一定的模式来生成错误或者警告信息，举例：

//当doAuthenticate方法在SecurityAspect以外调用时，生成警告
declare      warning: 
    call(void Authenticator.doAuthenticate()) //切入点：方法被调用的地方，与execution不同
    && !within(SecurityAspect)  : //切入点，不在SecurityAspect内
        
        "Authentication should be performed only by SecurityAspect";

这种场景下，本质上还是Spring基于JDK动态代理的AOP机制，只是借用AspectJ的语法。

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xmlns:aop="http://www.springframework.org/schema/aop"
    xsi:schemaLocation="
    http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
    http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
    ">
    <!-- 提示Spring自动为目标对象创建代理 -->
    <aop:aspectj-autoproxy />
    <!-- 声明普通Bean -->
    <bean id="messageCommunicator" class="cc.gmem.aj.MessageCommunicator" />
    <!-- 声明切面Bean，注意，必须使用注解语法定义切面 -->
    <bean id="securityAspect" class="cc.gmem.aj.SecurityAspect" />
</beans>

可以基于AspectJ，而不是Spring AOP来实现：事务管理、缓存、任务调度等常用AOP场景，以避免Spring AOP的固有缺陷。
特别是使用@Configurable注解来支持非Spring Bean的依赖注入，必须基于AspectJ完成。

<!-- 支持非受管对象（Spring Bean）的依赖注入和生命周期注解 -->
<context:spring-configured />
<!-- 支持基于AspectJ的事务管理 -->
<tx:annotation-driven transaction-manager="txManager" mode="aspectj" />
<!-- 支持基于AspectJ的缓存机制-->
<cache:annotation-driven cache-manager="cacheManager" mode="aspectj" />
<!-- 支持基于AspectJ的任务调度和执行 -->
<task:annotation-driven  scheduler="taskScheduler" executor="taskExecutor" mode="aspectj" />

The post AspectJ编程学习笔记 appeared first on 绿色记忆.

访问者模式表示一个作用于某对象结构中各元素的操作。 它允许在不改变各元素的类的前提下定义作用于这些元素的新操作。在GOF95中，该模式被分类为行为型模式。

1. Visitor：访问者接口，为所有元素声明一个visit方法，用来代表为此元素添加的功能
2. ConcreteVisitor：具体访问者实现，实现一组完整的应用到对象结构的功能
3. Element：抽象元素，代表对象结构中具体的元素，定义接收访问的操作
4. ConcreteElement：具体元素，亦即被访问对象，通常会回调访问者的真实功能，同时开放自身的数据供访问者使用
5. ObjectStructure：对象结构，通常包含多个可被访问的元素，它可以遍历多个被访问的元素，也可以让访问者直接访问元素。该对象可以持有若干Element的集合，或者具有多个Element类型的字段

访问者模式的价值在于可以透明的为对象结构添加新功能，避免对这一系列的对象进行修改。

访问者模式的优点：

1. 更好的可扩展性：允许通过创建新的访问者来增加行为，而无需改变对象结构本身
2. 行为的代码被放在一起，统一位于访问者内，易于维护
3. 分离无关行为：相互之间无关的行为被封装到不同的访问者中

访问者模式的缺点：

1. 允许访问者对这些内部元素进行访问，对象结构的内部封装被打破
2. 由于访问者对结构进行遍历，对象结构的修改变得困难，因为牵涉到所有访问者的修改

访问模式的适用场景：

1. 如果需要对一个对象结构实施一些依赖于具体元素的操作
2. 如果需要对一个对象结构中的各元素实施很多不同、不相关的操作
3. 如果对象结构很少变动，但是经常需要对元素添加新功能

这是一个变形的访问者模式，元素：文件、目录等没有统一的接口，也不能accept()访问者，实质上，对访问者的回调是由FileTreeWalker.walk()方法手动判断和完成的。FileTreeWalker相当于ObjectStructure角色。

ASM是Java的一个字节码处理框架，它定义的访问者模式允许访问类中的各种元素：类本身、方法、字段、注解等：

Dom4j是一个XML解析框架，它实现了非常典型的访问者模式：Visitor接口定义了访问各种XML节点的操作，包括文档、元素、属性、文本等。Node接口相当于Element角色，它为所有类型的XML节点定义了accept()方法。Document接口的实现AbstractDocument则充当了ObjectStructure角色：

public abstract class AbstractDocument extends AbstractBranch implements Document {
    public void accept(Visitor visitor) {
        visitor.visit(this); //先让访问者访问自己
        DocumentType docType = getDocType();
        if (docType != null) {
            visitor.visit(docType);  //访问文档类型
        }
        List content = content();
        //遍历，访问所有子节点
        if (content != null) {
            for (Iterator iter = content.iterator(); iter.hasNext();) {
                Object object = iter.next();
                if (object instanceof String) {
                    Text text = getDocumentFactory()
                            .createText((String) object);
                    visitor.visit(text);  //访问文本
                } else {
                    //如果是节点，那么调用相应的accept，递归的处理整个XML文档
                    Node node = (Node) object;
                    node.accept(visitor);
                }
            }
        }
    }
}

 Dom4j的访问者模式类图如下：

1. 与缺省适配模式联用：如果元素种类特别多，则应当引入一个实现了缺省适配的访问者抽象类，提供缺省适配，这样可以减少具体访问者的代码量
2. 与组合模式联用：将Component中定义的业务方法抽取出来，改用accept()方法，然后将那些业务方法的逻辑转移到访问者中
3. 退化：取消Element接口。这种情况下，各元素没有一致的接口，不能accept()访问者。那么把哪些元素传递给访问者对应方法的职责就落到ObjectStructure头上了

The post 访问者模式 appeared first on 绿色记忆.

对象创建后，即不允许改变其内部状态。 

不变模式不需要类图来描述。

不变模式分为两者形式：

1. 弱不变模式：当前类的实例的状态是不会变化的，但是其子类的实例状态则可能变化
2. 强不变模式：不但当前类的实例状态不会变化，子类实例的状态也不会变化

不变模式的优点：

1. 允许多个Client共享一个对象
2. 允许安全性浅拷贝
3. 允许避免并发访问时的同步开销 

Java的字符串和所有数字类型，都实现了不变模式，不提供任何操作来修改对象的内部状态：

一些“貌似”修改对状态的方法，实质上是返回了一个新的对象，例如String.trim()、BigDecimal.add()：

public BigDecimal add(BigDecimal augend) {
    ...
    return (fst.signum == snd.signum) ? 
        new BigDecimal(sum, INFLATED, rscale, 0) :
        new BigDecimal(sum, compactValFor(sum), rscale, 0);
}

在C++中，可以使用const关键字强制施加不变性约束：

class Immutable
{
    private:
        int field;

    public:
        Immutable( int f ) :
                field( f )
        {
        }
        void op()
        {
        }
        //声明为常方法，即不会改变对象的任何内部状态
        void constOp() const
        {
            op(); //无法通过编译，常方法不得调用非常方法
            this->field = 1; //无法通过编译，常方法不得对字段进行写操作
            Immutable::staticField = 1; //静态字段的修改则不在限制
        }
};

1. 与享元模式联用：由于不变模式的对象的内部状态不会改变，因而它可以被安全的享元

The post 不变模式 appeared first on 绿色记忆.

使用原型实例指定创建对象的种类，并通过拷贝这些原型对象创建新的对象。 在GOF95中原型模式被分类为创建型模式。

1. Prototype：声明一个克隆自身的接口，用来约束想要克隆自己的类，让它们都要实现这里定义的克隆方法
2. ConcretePrototype：实现Prototype接口的类，真正实现了对自身的克隆功能
3. Client：客户端，首先获取原型实例对象，然后通过克隆原型来创建新的实例

原型模式优点：

1. 向客户隐藏创建新实例的复杂性
2. 在某些情况下，复制对象比创建新对象更有效 

在Java语言中，所有类型的根类java.lang.Object支持克隆方法：

public class Object
{
    /**
     * 返回当前对象的一个拷贝，拷贝的含义依赖于对象的真实类型，但是一般意味着：
     * x.clone() != x && x.clone().getClass() == x.getClass() && x.equals(x.clone())
     * 
     * 根据惯例，该方法返回值应当和当前对象是相互独立的，这意味着可能需要将super.clone()
     * 返回的对象进行一定的处理，这个修改往往意味着对可变（mutable）对象进行深拷贝，如果当前
     * 类型只包含基本类型，则不需要这一处理过程
     * 
     * 当前实现实际上实现了浅拷贝行为：
     * 1、如果当前对象没有实现Cloneable，抛出CloneNotSupportedException
     *    注意所有数组类型被认为实现了Cloneable
     * 2、否则，创建一个新实例，并把当前对象的所有字段赋值给这个实例
     *    注意任何字段本身都不会被clone()
     */
    protected native Object clone() throws CloneNotSupportedException;
}

需要支持克隆功能的类型必须首先标记接口：

public interface Cloneable { }

可以看到，在JDK中已经内置的原型模式的支持。 

JavaScript从语言层次上支持了原型模式，实际上，JavaScript的继承机制就是基于原型的继承，而不是基于类的继承。

设置一个构造函数的prototype属性为一个对象，这个对象就成为此构造函数创建出的所有对象的原型：

var protoObject = { x: 1, y: 2, z: [1, 2] };
var ConstructFunc = function(){};

var obj1 = new ConstructFunc();
console.log(obj1.z); // 从原型继承得到的属性 [1, 2]
obj1.z.push(3);

var obj2 = new ConstructFunc();
console.log(obj2.z); //[1, 2, 3] 原型对象的属性是浅复制的

1. 深克隆与浅克隆：在使用原型模式的时候，涉及到两种克隆方式。深克隆会递归的克隆所有字段；浅克隆只是拷贝复杂类型的引用地址
2. 与工厂模式的比较：两者都用来创建对象实例，但是原型模式强调使用克隆的方式来创建
3. 与生成器模式联用：原型模式可以用来创建某些部件

The post 原型模式 appeared first on 绿色记忆.

在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这一状态。以后可以将对象恢复到原先保存的状态。备忘录模式在GOF95中被分类为行为型模式。 

1. Memento：备忘录接口，用来存放原发器对象某个瞬间的内部状态，该接口通常是空接口或者窄接口，不会声明任何获取原发器内部状态的方法
2. MementoImpl：备忘录实现类，为了不破坏封装性，备忘录的实现类往往作为原发器私有内部类实现，备忘录的实例应该由原发器自己生成
3. Originator：原发器，其状态需要保存和恢复，提供这两个接口
4. CareTaker：备忘录管理者，负责保存和取回备忘录

备忘录模式的优点：

1. 将被存储的状态放在外面，不和关键对象混在一起，提高了后者内聚性
2. 保持了关键对象的数据封装
3. 提供了容易实现的恢复能力

备忘录的缺点：

1. 存储和恢复状态的过程可能比较耗时
2. 如果存储的备忘录数量很大，可能导致不必要的开销

备忘录的适用场景：

1. 需要持久化对象状态，以便未来恢复时

串行化机制可以认为是一种备忘录模式，任何实现java.io.Serializable接口的类都相当于Originator角色：

import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;

public class SerializableObject implements java.io.Serializable
{
    private static final long serialVersionUID = 1L;
    private int               field0;
    private String            field1;
    //transient关键字用来声明不需要保存的状态
    private transient int     field2;
    //特殊签名的方法用来定制备忘录生成的具体规则，承担了createMemento()、restoreMemento()的职责
    private void writeObject( ObjectOutputStream out ) throws IOException {
        out.writeInt( field0 );
        out.writeUTF( field1 );
    }
    private void readObject( ObjectInputStream in ) throws IOException {
        field0 = in.readInt();
        field1 = in.readUTF();
    }
}

而Memento角色则由使用二进制数据流承担，没有对应的Java对象。CareTaker角色由java.io包中一些类承担：

SerializableObject so = new SerializableObject();
ObjectOutputStream output = new ObjectOutputStream( new FileOutputStream( "SerializableObject" ) );
output.writeObject( so );
output.close();

ObjectInputStream input = new ObjectInputStream( new FileInputStream( "SerializableObject" ) );
so = (SerializableObject) input.readObject();
input.close();

1. 增量备忘录：如果原发器的状态很多，而修改的状态很少，可以使用增量方式存储备忘录
2. 与原型模式联用：如果原发器的大部分字段都是需要保存的，那么原发器可以实现原型模式，保存备忘录的时候直接保存原发器的克隆
3. 离线存储：标准的备忘录模式没有考虑到离线存储的问题，实际上CareTaker可以将备忘录保存为XML、JSON、Java串行化格式，甚至保存到数据库
4. 与命令模式联用：命令模式支持撤销，这就涉及到对象状态恢复的问题。可以在执行命令时，将出现变化的状态原值保存到备忘录中，在撤销时，取回备忘录恢复

The post 备忘录模式 appeared first on 绿色记忆.

也译为“调停者模式”，该模式用一个中介对象来封装一系列的对象交互。中介者使得各对象不需要显式的相互引用，从而使其松散耦合，而且可以独立的改变它们之间的交互。在GOF95中中介者模式被分类为行为型模式。 

1. Mediator：中介者接口，在里面定义各同事之间交互需要的方法。可以是公共的通信方法，比如changed，大家都用；也可以是小范围的交互方法
2. ConcreteMediator：具体的中介者实现，持有所有同事的引用，并协调各同事之间的交互关系
3. Colleague：同事抽象类，主要负责约束同事的类型，不实现同事的公共功能，比如每个同事都应该知道中介者对象（getMediator）
4. ConcreteColleague：具体同事类，实现自己的业务，它们直接绝不存在任何依赖关系。它们如果需要与其它同事通信，就持有中介者的引用

中介者模式很好的体现了迪米特法则，它可以彻底解耦网状的对象关系。

中介者模式的优点：

1. 通过将对象彼此解耦，可以增加对象的复用度
2. 通过将控制逻辑集中，可以简化系统维护
3. 可以让对象之间传递的消息变得简单而且大幅减少
4. 将多对多关系改变为一对多

中介者模式的缺点：

1. 如果设计不当，中介者对象本身会变得过于复杂

中介者模式的适用场景：

1. 如果一组对象之间的通信方式过于复杂，导致结构混乱的互相依赖
2. 用来协调相关的GUI组件

public class Method{
    public Object invoke(Object obj, Object... args)
	throws IllegalAccessException, IllegalArgumentException;
}

Method类实现了一种变形的中介者模式，Method相当于Mediator角色，调用invoke()的Client代码相当于Colleague角色，invoke()的obj参数也相当于Colleague角色。虽然Client持有了需要交互的Colleague的引用，但是它不需要知道Colleague类型的任何信息。

1. 退化：取消同事的公共抽象类。如果不同的同事类没有什么公共功能，仅仅一个getMediator()往往不值得让它们拥有公共父类
2. 退化：具体中介者作为单例。如果只需要一个中介者对，那么可以用单例实现
3. 退化：取消中介者接口。如果不可能有切换中介者的需求，可以取消此接口 
4. 与外观模式的比较：两者都很好的提现迪米特法则。但是外观模式对系统内部进行封装，对Client提供单向的接口；而中介者模式则来协调系统内部的多个组件，并且通信是双向的

The post 中介者模式 appeared first on 绿色记忆.