系统架构师笔记（二）
- - CSDN博客Web前端推荐文章今年的系统架构师考试马上就要开始了，在此进行了一次核心要点总结，与大家一起分享. 七、架构权衡分析法：ATTM（Architecture Tradeoff Analysis Method）. 评价软件架构的一种综合全面的方法. 这种方法不仅可以揭示出构架满足特定质量目标的情况，而且（因为它认识到了构架决策会影响多个质量属性）可以使我们更清楚地认识到质量目标之间的联系——即如何权衡诸多质量目标.
系统架构师笔记（一）
标签：
系统
架构师
笔记
| 发表时间：2013-11-07 21:53 | 作者：cl05300629
出处：http://blog.csdn.net
今年的系统架构师考试马上就要开始了，在此进行了一次核心要点总结，与大家一起分享。
一、质量属性：
1、性能：系统的响应能力，即要经过多长时间才能对某个事件作出响应或者在某段时间内系统所能处理事件的个数。架构设计策略：增加计算资源、改善资源需求（减少计算复杂度等）、资源管理（并发、数据复制等）和资源调度（先进先出队列、优先级队列等）
2、可用性：系统能够正常运行的时间比例。架构设计策略：Ping/Echo、心跳、异常和信息主动冗余等。
3、可靠性：软件系统在应用或错误面前，在意外或错误使用的情况下维持软件系统功能性的能力。架构设计策略：运行时注册，主动冗余 可靠性的计算、检错技术和容错技术
4、健壮性：处理环境中，系统能够承受压力或变更的能力。
5、安全性：系统向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。架构设计策略：抵御攻击（授权、认证和限制访问等）、攻击检测（入侵检测等）、从攻击中恢复（部分可用性策略）和信息审计等。
6、可修改性：能快速的以较高的性能价格比对系统进行变更。架构设计策略：软件模块泛化、限制模块之间通信、使用中介、信息隐藏、延迟绑定等。
7、可变性：体系结构经扩充或变更成为新体系结构的能力。
8、易用性：用户使用一个软件产品完成指定任务的难易程度。
9、可测试性：软件发现故障并隔离、定位其故障的能力特性，以及在一定时间或成本前提下，进行测试设计、测试执行的能力。架构设计策略：记录-回放
10、功能性：系统所能完成所期望工作的能力。
11、互操作性：系统与外界或系统与系统之间的相互作用的能力。
二、“4+1”视图
对逻辑架构进行描述，最早由 Philippe Kruchten 提出，他在1995年的《IEEE Software》上发表了题为《The 4+1 View Model of Architecture》的论文，引起了业界的极大关注，并最终被 RUP 采纳，现在已经成为架构设计的结构标准。
逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。
过程视图（Process View），捕捉设计的并发和同步特征。
物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。
开发视图（Development View），描述了在开发环境中软件的静态组织结构。
架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例 （use cases）或场景(scenarios)来说明，从而形成了第五个视图。
三、经典软件体系结构风格
1、虚拟机风格：java虚拟机
2、事件驱动风格：图形用户界面
3、管道-过滤器风格：数据内容的逐步分解与分阶段处理。适合服务器服务端处理软件的要求。
4、隐式调用风格：回调机制，集成调试器，根据外部事件进行响应的场景。
5、解释器风格：强调用户定义系统中对象的关系和行为这一特性，需要在软件架构层面提供一种运行时的系统行为定义与改变的能力。
6、过程控制风格：实时获取外界信息，与用户自定义信息进行比较并作出动作。
7、黑板风格：正确结果不止一个，求解过程比较复杂，需要通过专家只是和反馈逐步得到正确的结果。比如人工智能等。
8、数据共享风格：关注编译过程和程序的中间表示，围绕程序的各种形态进行转化与处理，针对程序的各种形态建立数据库，通过中心数据库进行转换与处理。
四、架构模式、惯用法、设计模式
1、架构模式：设计软件中的高层决策，反映了开发软件系统过程中所做的基本设计决策；
2、设计模式：主要关注软件系统的设计，与具体的实现语言无关；
3、惯用法：实现时通过某种特定的程序设计语言来描述构建于构建之间的关系，例如C++语言中的引用-计数
五、设计模式
1、装饰模式：能够动态的对一个对象进行功能上的扩展，也可以对其子类进行功能上的扩展。
2、观察者模式：对于某个具体固定结构的活动节点需要多种处理能力，且处理能力可扩展，也就说要求在不改变原来类结构（活动节点）的基础上增加新功能。
3、工厂模式：定义一个用于创建对象的接口，让子类决定实例化哪一个类
4、责任链模式：很多对象由每一个对象对其下家的引用而连接起来形成一条链，请求在这个链上传递，直到链上的某个对象决定处理此请求。
5、中介者模式：用一个中介者对象封装一系列的对象交互。
6、代理模式：提高系统效率，避免同时创建对象。
7、命令模式：将请求、动作封装成对象，以便使用不同的请求、队列或者日志来参数化其他对象。
8、组合模式：（整体-部分模式）通过多个对象形成属性结构以表示整体-部分的结构层次。对单个对象（叶子对象）和组合对象（容器对象）的使用具有一致性。
六、权衡点和敏感点
敏感点是一个或多个构件（或之间的关系）的特性
权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。
其实绝大多数考虑都是基于权衡点来考虑的，在某个权衡点上考虑时，某些构件对于某一点比较敏感。可见敏感点是从构件角度来考虑，权衡点是从构件交互的角度来考虑。
权衡点是影响多个质量属性的特性，是多个质量属性的敏感点。
其实绝大多数考虑都是基于权衡点来考虑的，在某个权衡点上考虑时，某些构件对于某一点比较敏感。可见敏感点是从构件角度来考虑，权衡点是从构件交互的角度来考虑。
作者：cl05300629 发表于2013-11-7 13:53:57 原文链接
阅读：123 评论：0 查看评论
相关 [系统 架构师 笔记] 推荐：
系统架构师笔记（一）
- - CSDN博客架构设计推荐文章今年的系统架构师考试马上就要开始了，在此进行了一次核心要点总结，与大家一起分享. 1、性能：系统的响应能力，即要经过多长时间才能对某个事件作出响应或者在某段时间内系统所能处理事件的个数. 架构设计策略：增加计算资源、改善资源需求（减少计算复杂度等）、资源管理（并发、数据复制等）和资源调度（先进先出队列、优先级队列等）.
系统架构师JD
- - CSDN博客架构设计推荐文章国内大型的物流企业，专业从事国内公路运输和航空运输代理. Foss项目的架构设计，包括需求分析，模块设计，系统结构设计，关键功能的开发，技术难题的解决，对团队质量输出的把控等等. 1、熟悉WebLogic/Websphere/JBoss等一个以上大型应用服务器，熟悉Linux及应用服务器集群. 2、 具有丰富J2EE架构设计经验，具有大型基于J2EE体系结构的项目规划、系统架构设计、开发经验.
对大宋下一代系统软件架构师的七个期望
- joyoner - 弯曲评论有诗云：人之老，其言真；人之去；其行善. 系统软件设计是软件系统的皇冠中的宝石. 在系统软件，特别是通信系统软件的设计上，有没有一些可以提炼的方法论. 今身处幽州（北平），心在大宋. 谈谈我对大宋年轻一代的系统软件工程师的期望. 年轻人都以为有些事情需要粗，有些事情需要厚. 系统软件一定要越细越好；越薄越好.
推荐系统的学习笔记
- - CSDN博客综合推荐文章一直以来对推荐系统的学习和理解来自一些机器学习书中简单介绍（如《集体智慧编程》和《机器学习实战》）和自己网上搜的一些资料. 而当被问及对推荐系统的改进和理解，发现自己对推荐系统所知甚少，除了知道几个常用的算法外，根本没有更深入的理解，更别提改进了. 本篇博客为学习《推荐系统》一书的读书笔记，记录了常见的推荐算法和其思想.
腾讯海外计费系统架构演进 | TEGer在全球架构师峰会
- -作者简介：abllen，2008年加入腾讯，一直专注于腾讯计费平台建设，主导参与了腾讯充值中心、计费开放平台、统一计费米大师等项目，见证了米大师从0到1，业务营收从PC到移动多终端再到全球化的跨越过程. 目前专注于跟团队一起为腾讯业务提供稳定高效安全的全球化个人和企业市场计费服务. 经过海外3年建设，腾讯Midas（米大师）计费逐步构建起了一个分布式的全球计费系统，来助力公司及业内产品计费扬帆出海，走向深蓝.
分布式系统 读书笔记（二）数据平滑迁移
- - 企业架构 - ITeye博客在开始进行数据迁移时，记录增量的日志，在迁移结束后，再对增量变化进行处理. 在最后，可以把要迁移的数据的写暂停，保证增量日志都处理完毕后，再切换规则，放开所有的写，完成迁移工作. 我们希望根据id去模把上面这个表 划分到两个数据库中， 也就是id mod 2 为0的还在原数据库 为1的在新库中.
微服务与架构师
- - 乱象，印迹因为工作的关系，最近面试了很多软件架构师，遗憾的是真正能录用的很少. 很多候选人有多年的工作经验，常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”，如果遇到的问题没有严格对应的现成框架，就比较吃力. 这样的技能水平或许适合某些行业，但很遗憾不符合我们的要求. 软件架构师到底应该做什么，又为什么这么难做好，这都是近来的热门问题，我也一直在和朋友们讨论.
架构师图谱（上）
- - DockOne.io“架构师图谱”是一个很宏大的命题，特别是优秀的架构师自身也是“由点到面再到图”，一点点成长积累起来，尝试写这篇文章的目的更多的是结合自身的一些架构、研发、管理经验对现阶段做一个复盘总结，所以这里更偏向于后端图谱，依赖于开源技术、云原生或者其他第三方服务. 这里会重点介绍一些技术栈、设计理念以及适应场景，这些可以作为我们选型时的依据.
分布式系统 读书笔记（三）跨库查询的问题和及解决
- - 企业架构 - ITeye博客如果一个查询涉及多个库或者多张分表 结果该如何处理. 1.排序，即多个来源的数据查询出来以后，在应用层进行排序的工作. 查出来如果是已经排序号的，则对多路进行归并排序否则就要进行一个全排序. 2.函数处理，即使用Max,Min,Sum,Count 等函数对多个数据来源的值进行相应的函数处理. 3.求平均值，从多个数据来源进行查询时，需要把SQL改为查询SUM和Count，然后对多个数据来源的Sum求和，count求和后，计算平均值，这是需要注意的地方.