系统架构师学习笔记

1.系统架构师的职责主要有如下4条：
1、确认需求
在项目开发过程中，架构师是在需求规格说明书完成后介入的，需求规格说明书必须得到架构师的认可。架构师需要和分析人员反复交流，以保证自己完整并准确地理解用户需求。
2、系统分解
依据用户需求，架构师将系统整体分解为更小的子系统和组件，从而形成不同的逻辑层或服务。随后，架构师会确定各层的接口，层与层相互之间的关系。架构师不仅要对整个系统分层，进行“纵向”分解，还要对同一逻辑层分块，进行“横向”分解。
软件架构师的功力基本体现于此，这是一项相对复杂的工作。
3、技术选型
架构师通过对系统的一系列的分解，最终形成了软件的整体架构。技术选择主要取决于软件架构。
Web Server运行在Windows上还是Linux上？数据库采用MSSql、Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这个阶段提出，并进行评估。
架构师对产品和技术的选型仅仅限于评估，没有决定权，最终的决定权归项目经理。架构师提出的技术方案为项目经理提供了重要的参考信息，项目经理会从项目预算、人力资源、时间进度等实际情况进行权衡，最终进行确认。
4、制定技术规格说明
架构师在项目开发过程中，是技术权威。他需要协调所有的开发人员，与开发人员一直保持沟通，始终保证开发者依照它的架构意图去实现各项功能。
架构师不仅要保持与开发者的沟通，也需要与项目经理、需求分析员，甚至与最终用户保持沟通。所以，对于架构师来讲，不仅有技术方面的要求，还有人际交流方面的要求。

########经验只谈

http://blog.csdn.net/iammerryz/article/details/7644921

###### http://blog.sina.com.cn/s/blog_493a84550101cfen.html

在这里再谈下应用架构和技术架构的关系和边界问题，这里的说明和标准的TOGAF会有一些区别，仅为个人理解的一些点滴记录。

首先再说下应用架构，应用架构是和业务架构有强烈的映射关系的一个架构，应用架构要说明的是整体企业内部信息化建设和规划应该分为哪些应用系统去建设，应用系统间的集成关系是如何的。即我们常说的应用架构和应用集成架构。业务架构只关系核心的业务流程，业务域，业务组件识别出来即可，应用架构在业务架构的基础上多考虑两个事情，一个是究竟如何来划分业务系统，业务系统的划分粒度如何？如何满足划分后的业务系统间的高内聚松耦合；第二个是在业务架构转换到应用架构去规划后续建设实施的时候，应该有哪些内容可复用的识别，将可复用的内容和资源共享的内容下沉到我们说的平台层，将业务系统间需要协同和整合分析的内容上升到我们常说的门户层和BI展示层。解决完这两个问题即完成业务系统朝应用架构的转化。

简单来将应用架构中的所有点都是应该后续可以规划建设的应用系统或平台。企业后续需要建设一个安全管理平台，虽然和业务无关，但是应该体现在应用架构的PaaS平台层。企业整个应用建设需要考虑IT基础设施资源池虚拟化和整合，需要体现在应用架构的IaaS基础平台层。企业没有这种单独抽出来独立建设的规划，就不用体现到应用架构中，而该点仅仅变化为应用系统中建设需要考虑的一个技术点，直接在技术架构中解决。

我原来一直强调过在产品开发里面的一个重要思路，即分为产品，平台和技术三个层面的内容。如果和这个分类方法对应，则产品和平台都应该体现在应用架构总体框架中，平台本身又分了IaaS层平台和PaaS层平台。而技术则体现在技术架构这个概念里面。即我们谈到技术架构和产品架构，平台架构都是一种松耦合的关系。技术架构本身不能形成平台或产品，而是需要在应用建设，平台建设中考虑究竟需要使用哪些技术，如何使用。产品中需要使用平台，也还需要使用平台中未涵盖的额外技术，平台建设中也需要使用各自关键技术，这些都需要体现在技术架构中进行统一的规划和考虑。

应用架构本身只关心需要有哪些应用系统，哪些平台来满足业务目标的需求，而不会关系在整个构建过程中你需要使用哪些技术；技术架构是接应用架构的技术需求，并根据识别的技术需求，进行技术的选型，并把各关键技术和技术之间的关系描述清楚。大家可以关注下互联网上各自技术架构分享资料，你最多知道一个大的业务场景，其它内容全是采用了什么样的技术，什么样的开源组件，这些技术融合在一起解决了哪些问题。而实际的应用系统长什么样子，有哪些具体的功能点在技术架构中是完全看不到的。

再回来看技术架构，技术架构解决的问题包括了如何进行纯技术层面的分层，开发框架选择，语言选择，涉及到各自非功能性需求的技术点（安全，性能，日志，异常，缓存，消息，大数据量）等需要使用的关键技术。由于我们的应用架构体系本身是分层的，那自然有和其对应的技术架构体系，大的分层包括了SOA参考架构分层模型，小的分层则是单个应用的技术分层多层框架。这些都考虑清楚的剩下的问题就简单了，即根据实际的业务场景模拟来验证各个技术点间的协同，各技术点最终形成技术组件，各个技术组件间也需要高可靠集成。

技术架构是对应用架构的一个完整支撑，应用架构和技术架构都描述清楚后还应该考虑和验证当前技术架构是否可以完整的支撑应用建设。应用架构是给技术架构输入具体的应用建设需求变转换为具体的技术需求点，各个技术点的分析，方案选型，最终形成关键技术清单，关键技术清单考虑应用架构本身的分层逻辑形成一个完整的技术架构图。对于IT基础设施架构我们常常将其纳入技术架构范畴，但是不是全部。对于单个应用系统建设的时候谈到应用本身的MVC模式分层框架更加仅仅是技术架构的一部分内容。