系统架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。一个架构师得需要足够的想像力,能把各种目标需求进行不同维度的扩展，为目标客户提供更为全面的需求清单。
软件架构入门
作者： 阮一峰
日期： 2016年9月 3日
软件架构（software architecture）就是软件的基本结构。
合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位（architect），只有资深程序员才可以担任。
O’Reilly 出版过一本免费的小册子《Software Architecture Patterns》（PDF）， 介绍了五种最常见的软件架构，是非常好的入门读物。我读后受益匪浅，下面就是我的笔记。
一、分层架构
分层架构（layered architecture）是最常见的软件架构，也是事实上的标准架构。如果你不知道要用什么架构，那就用它。
这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。
虽然没有明确约定，软件一定要分成多少层，但是四层的结构最常见。
表现层（presentation）：用户界面，负责视觉和用户互动
业务层（business）：实现业务逻辑
持久层（persistence）：提供数据，SQL 语句就放在这一层
数据库（database） ：保存数据
有的软件在逻辑层和持久层之间，加了一个服务层（service），提供不同业务逻辑需要的一些通用接口。
用户的请求将依次通过这四层的处理，不能跳过其中任何一层。
优点
结构简单，容易理解和开发
不同技能的程序员可以分工，负责不同的层，天然适合大多数软件公司的组织架构
每一层都可以独立测试，其他层的接口通过模拟解决
缺点
一旦环境变化，需要代码调整或增加功能时，通常比较麻烦和费时
部署比较麻烦，即使只修改一个小地方，往往需要整个软件重新部署，不容易做持续发布
软件升级时，可能需要整个服务暂停
扩展性差。用户请求大量增加时，必须依次扩展每一层，由于每一层内部是耦合的，扩展会很困难
二、事件驱动架构
事件（event）是状态发生变化时，软件发出的通知。
事件驱动架构（event-driven architecture）就是通过事件进行通信的软件架构。它分成四个部分。
事件队列（event queue）：接收事件的入口
分发器（event mediator）：将不同的事件分发到不同的业务逻辑单元
事件通道（event channel）：分发器与处理器之间的联系渠道
事件处理器（event processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作
对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。
优点
分布式的异步架构，事件处理器之间高度解耦，软件的扩展性好
适用性广，各种类型的项目都可以用
性能较好，因为事件的异步本质，软件不易产生堵塞
事件处理器可以独立地加载和卸载，容易部署
缺点
涉及异步编程（要考虑远程通信、失去响应等情况），开发相对复杂
难以支持原子性操作，因为事件通过会涉及多个处理器，很难回滚
分布式和异步特性导致这个架构较难测试
三、微核架构
微核架构（microkernel architecture）又称为”插件架构”（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。
内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。
优点
良好的功能延伸性（extensibility），需要什么功能，开发一个插件即可
功能之间是隔离的，插件可以独立的加载和卸载，使得它比较容易部署，
可定制性高，适应不同的开发需要
可以渐进式地开发，逐步增加功能
缺点
扩展性（scalability）差，内核通常是一个独立单元，不容易做成分布式
开发难度相对较高，因为涉及到插件与内核的通信，以及内部的插件登记机制
四、微服务架构
微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。
每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。
微服务架构分成三种实现模式。
RESTful API 模式：服务通过 API 提供，云服务就属于这一类
RESTful 应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部
集中消息模式：采用消息代理（message broker），可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群
优点
扩展性好，各个服务之间低耦合
容易部署，软件从单一可部署单元，被拆成了多个服务，每个服务都是可部署单元
容易开发，每个组件都可以进行持续集成式的开发，可以做到实时部署，不间断地升级
易于测试，可以单独测试每一个服务
缺点
由于强调互相独立和低耦合，服务可能会拆分得很细。这导致系统依赖大量的微服务，变得很凌乱和笨重，性能也会不佳。
一旦服务之间需要通信（即一个服务要用到另一个服务），整个架构就会变得复杂。典型的例子就是一些通用的 Utility 类，一种解决方案是把它们拷贝到每一个服务中去，用冗余换取架构的简单性。
分布式的本质使得这种架构很难实现原子性操作，交易回滚会比较困难。
五、云架构
云结构（cloud architecture）主要解决扩展性和并发的问题，是最容易扩展的架构。
它的高扩展性，主要原因是没使用中央数据库，而是把数据都复制到内存中，变成可复制的内存数据单元。然后，业务处理能力封装成一个个处理单元（prcessing unit）。访问量增加，就新建处理单元；访问量减少，就关闭处理单元。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里，最好要进行数据持久化。
这个模式主要分成两部分：处理单元（processing unit）和虚拟中间件（virtualized middleware）。
处理单元：实现业务逻辑
虚拟中间件：负责通信、保持sessions、数据复制、分布式处理、处理单元的部署。
虚拟中间件又包含四个组件。
消息中间件（Messaging Grid）：管理用户请求和session，当一个请求进来以后，决定分配给哪一个处理单元。
数据中间件（Data Grid）：将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据。
处理中间件（Processing Grid）：可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元
部署中间件（Deployment Manager）：负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元。
优点
高负载，高扩展性
动态部署
缺点
实现复杂，成本较高
主要适合网站类应用，不合适大量数据吞吐的大型数据库应用
较难测试
（完）
亚马逊如何变成 SOA（面向服务的架构）？
作者： 阮一峰
日期： 2016年9月10日
上一篇文章，我摘录了《程序员的呐喊》。这本书有趣的内容太多，今天再摘录一段。
1、
亚马逊公司不仅是世界最大的网络书店，还是世界最大的云服务商。它是怎么实现从电商到云商的转变呢？
一切都是CEO杰夫·贝索斯促成的，他对市场有着超乎常人的理解和预见。
2、
2000年前后，贝索斯有一次在员工大会上提到，各种办公工具、书籍、影音制品都可以数字化，所以也意味着很容易盗版。数字产品可能会利润越来越低，很快就不再产生任何收入了。
所有的民用工业品也都很不妙，服装和电子消费品的消费周期越来越短。连烤炉这种东西，也没人想要去年的型号。总之，卖这些东西，看上去也不太会赚大钱。
亚马逊未来靠什么赚钱，贝索斯不仅忧心忡忡。
3、
2002年，贝索斯突然向全公司发布了一道指令。
（1）从今天起，所有的团队都要以服务接口的方式，提供数据和各种功能。
（2）团队之间必须通过接口来通信。
（3）不允许任何其他形式的互操作：不允许直接链接，不允许直接读其他团队的数据，不允许共享内存，不允许任何形式的后门。唯一许可的通信方式，就是通过网络调用服务。
（4）具体的实现技术不做规定，HTTP、Corba、PubSub、自定义协议皆可。
（5）所有的服务接口，必须从一开始就以可以公开作为设计导向，没有例外。这就是说，在设计接口的时候，就默认这个接口可以对外部人员开放，没有讨价还价的余地。
（6）不遵守上面规定，就开除。
他意识到，亚马逊现有的卖书送书的基础设施，其实可以变成一个非常出色、可定制的计算平台，让用户付费使用。但是前提是，整个基础设施必须改造成面向服务的架构。
4.
接下来的几年里，亚马逊全公司都转向了面向服务的架构（SOA）。这个过程中，工程师们得到了大量的经验教训。
教训一：SOA架构的错误定位，非常麻烦。
一个请求可能要经过20次服务器调用，才能找到问题的真正所在。通常，单单是问题的定位就要花费15分钟到几个小时，除非搭建大量的外围监控和报警措施。
教训二：同事也是潜在的 DOS 攻击者。
公司内部某个小组，会突然对你的服务发起大量请求。除非每个服务都设有严格的用量和限量措施，否则根本无法保证可用性。
教训三：监控和质量保障（QA）是两回事。
监控一个服务的时候，可能会得到”一切正常”的回复。但是很有可能，整个服务唯一还正常工作的部分，就是这个回应”一切正常”的模块。只有完整地调用服务，才能确定服务是正常的。
这意味着，真正监控一个服务，必须做到对所有的服务和数据进行完整的语意检查，否则是看不出问题的。如果做到了这一点，本质上就是在做自动化 QA 了。
教训四：必须有服务发现机制。
面对成百上千的服务时，没有服务发现机制是不可想象的。这又离不开服务注册机制，而它本身也是一个服务。亚马逊有一套统一的服务注册机制，可以通过编程的方式找到所有服务，包括一个服务有哪些API，目前是不是运行正常，在什么位置等。
教训五：必须有沙箱用来调试
如果代码中调用了他人服务，查找问题的难度要高很多，除非有统一的方式在沙箱里运行所有服务，否则几乎不可能进行任何调试。
教训六：不能信任任何人
团队采用服务的方式进行合作以后，基本上就不能信任其他团队了，正如不能信任第三方工程师一样。
（完）
MVC，MVP 和 MVVM 的图示
作者： 阮一峰
日期： 2015年2月 1日
复杂的软件必须有清晰合理的架构，否则无法开发和维护。
MVC（Model-View-Controller）是最常见的软件架构之一，业界有着广泛应用。它本身很容易理解，但是要讲清楚，它与衍生的 MVP 和 MVVM 架构的区别就不容易了。
昨天晚上，我读了《Scaling Isomorphic Javascript Code》，突然意识到，它们的区别非常简单。我用几段话，就可以说清。
（题图：摄于瓦伦西亚，西班牙，2014年8月）
一、MVC
MVC模式的意思是，软件可以分成三个部分。
视图（View）：用户界面。
控制器（Controller）：业务逻辑
模型（Model）：数据保存
各部分之间的通信方式如下。
View 传送指令到 Controller
Controller 完成业务逻辑后，要求 Model 改变状态
Model 将新的数据发送到 View，用户得到反馈
所有通信都是单向的。
二、互动模式
接受用户指令时，MVC 可以分成两种方式。一种是通过 View 接受指令，传递给 Controller。
另一种是直接通过controller接受指令。
三、实例：Backbone
实际项目往往采用更灵活的方式，以 Backbone.js 为例。
用户可以向 View 发送指令（DOM 事件），再由 View 直接要求 Model 改变状态。
用户也可以直接向 Controller 发送指令（改变 URL 触发 hashChange 事件），再由 Controller 发送给 View。
Controller 非常薄，只起到路由的作用，而 View 非常厚，业务逻辑都部署在 View。所以，Backbone 索性取消了 Controller，只保留一个 Router（路由器） 。
四、MVP
MVP 模式将 Controller 改名为 Presenter，同时改变了通信方向。
各部分之间的通信，都是双向的。
View 与 Model 不发生联系，都通过 Presenter 传递。
View 非常薄，不部署任何业务逻辑，称为”被动视图”（Passive View），即没有任何主动性，而 Presenter非常厚，所有逻辑都部署在那里。
五、MVVM
MVVM 模式将 Presenter 改名为 ViewModel，基本上与 MVP 模式完全一致。
唯一的区别是，它采用双向绑定（data-binding） ：View的变动，自动反映在 ViewModel，反之亦然。Angular 和 Ember 都采用这种模式。
（完）
软件架构设计
作者: 温昱
出版社: 电子工业出版社
出版年: 2007-5
页数: 340
定价: 45.00元
装帧: 平装
ISBN: 9787121039461
内容简介 · · · · · ·
本书紧紧围绕“软件架构设计”这一主题，立足实践解析了软件架构的概念，阐述了切实可行的软件架构设计方法，提供了可操作性极强的完整的架构设计过程。另外，本书从思维方式的突破、面向对象设计、UML建模、过程与管理等关键过渡环节，为广大程序员的成长提供了切中肯綮的指导。本书可作为计算机软件专业本科生、研究生和软件工程硕士的软件架构设计教材，也可作为软件开发高级培训、软件开发管理培训的培训教材，更是第一线高级开发人员和开发管理人员的必备参考书。…
一线架构师实践指南
作者: 温昱
出版社: 电子工业出版社
出版年: 2009年10月
页数: 186
定价: 35.00元
ISBN: 9787121095405
内容简介 · · · · · ·
本书致力于为一线架构师，以及软件企业提供务实有效的架构设计方法指导。
本书从架构师经常遇到的困惑出发，总结软件架构设计中经常遇到的问题，提出“方法体系必然是软件业界未来发展的重大趋势”这一观点；之后，详细阐述了软件架构设计三个阶段（Pre-Architecture阶段、 Conceptual Architecture阶段和Refined Architecture阶段）中的各个具体环节，并给出了最佳的实践原则和方法，内容涵盖“需求进，架构出”的整个过程。
20多位专家撰文推荐。
作者10多年架构设计和咨询实践经验的总结。
实例讲解软件架构设计ADMEMS方法体系。
中大型系统架构设计的航标灯。
作者简介 · · · · · ·
温昱 资深咨询顾问，CSAI特聘高级顾问，软件架构专家。软件架构思想的传播者和积极推动者，中国软件技术大会杰出贡献专家。十年系统规划、架构设计和研发管理经验，在金融、航空、多媒体、电信、中间件平台等领域负责和参与多个大型系统的规划、设计、开发与管理。作为资深咨询顾问，已为众多知名企业提供了卓有成效的架构培训与咨询服务。
软件架构的艺术
作者: 李伟 / 吴庆海
出版社: 电子工业出版社
出版年: 2009-4
页数: 318
定价: 49.00元
ISBN: 9787121076701
内容简介 · · · · · ·
《软件架构的艺术》：架构是设计一切系统的基础和核心。随着用户需求的变化及技术的发展，我们身边各式各样的系统也日趋复杂。如何在万象中剥离繁华，提炼事物的本质和精髓，“系统架构”正是化繁为简、打通两极世界的一门艺术。
架构之美，在于和谐。本套“架构之美”系列丛书，以期从业务梳理、流程建模、软件架构、设计模式等方面进行系统、全面地介绍。强调理论与实践相结合，国外发展趋势与国内本地应用相结合，打造华人精品书籍，给国内读者提供真正有指导意义的美食大餐。
本书聚焦于软件架构行业，全面介绍软件应用系统架构的基本原理、方法以及经典的实践经验。把握共同的规律，预知未来的发展，选择最佳的路径，尽可能减少成长的烦恼，并保持成熟的稳定，让企业充分享受属于架构整个生命阶段的华彩！
软件架构师应该知道的97件事
作者: Richard Monson-Haefel
出版社: 电子工业出版社
译者: 徐定翔 / 章显洲
出版年: 2010-4
页数: 200
定价: 39.80元
装帧: 平装
ISBN: 9787121106354
内容简介 · · · · · ·
优秀的软件架构师应该既掌握业务知识又具备技术能力，做到这一点绝非易事，本书想要探讨的就是这个主题。这是一本真正的开源图书，我们邀请到50多位杰出的软件架构师参与写作。大家无偿地分享了各自的工作经验和心得，内容从规避风险的方法到组建团队的技巧，涵盖了架构设计的方方面面。衷心希望这97篇文章能激发您的思考，解决您工作中的困惑。
O’reilly第一本开源图书，业界专家集体智慧创作 。
旨在“为全世界的软件架构师提供洞察力和指导”。
集思广益、覆盖面广、写法新颖 。
技术社区及程序员博客热议 。
作者简介 · · · · · ·
蒙森-哈斐尔，O’Reilly出版的Enterprise JavaBeans和Java Message Service，First Edition两本书的合著者之一，企业计算领域全球领先的专家。
目录 · · · · · ·
前言
客户需求重于个人简历
简化根本复杂性，消除偶发复杂性
关键问题可能不是出在技术上
以沟通为中心，坚持简明清晰的表达方式和开明的领导风格
架构决定性能
分析客户需求背后的意义
起立发言
故障终究会发生
我们常常忽略了自己在谈判
量化需求
一行代码比五百行架构说明更有价值
不存在放之四海皆准的解决方案
提前关注性能问题
架构设计要平衡兼顾多方需求
草率提交任务是不负责任的行为
不要在一棵树上吊死
业务目标至上
先确保解决方案简单可用，再考虑通用性和复用性
架构师应该亲力亲为
持续集成
避免进度调整失误
取舍的艺术
打造数据库堡垒
重视不确定性
不要轻易放过不起眼的问题
让大家学会复用
架构里没有大写的“i”
使用“一千英尺高”的视图
先尝试后决策
掌握业务领域知识
程序设计是一种设计
让开发人员自己做主
时间改变一切
设立软件架构专业为时尚早
控制项目规模
架构师不是演员，是管家
软件架构的道德责任
摩天大厦不可伸缩
混合开发的时代已经来临
性能至上
留意架构图里的空白区域
学习软件专业的行话
具体情境决定一切
侏儒、精灵、巫师和国王
向建筑师学习
避免重复
欢迎来到现实世界
仔细观察，别试图控制一切
架构师好比两面神
架构师当聚焦于边界和接口
助力开发团队
记录决策理由
挑战假设尤其是你自己的
分享知识和经验
模式病
不要滥用架构隐喻
关注应用程序的支持和维护
有舍才有得
先考虑原则、公理和类比再考虑个人意见和口味
从“可行走骨架”开始开发应用
数据是核心
确保简单问题有简单的解
架构师首先是开发人员
根据投资回报率（roi）进行决策
一切软件系统都是遗留系统
起码要有两个可选的解决方案
理解变化的影响
你不能不了解硬件
现在走捷径，将来付利息
不要追求“完美”，“足够好”就行
小心“好主意”
内容为王
对商业方，架构师要避免愤世嫉俗
拉伸关键维度，发现设计中的不足
架构师要以自己的编程能力为依托
命名要恰如其分
稳定的问题才能产生高质量的解决方案
天道酬勤
对决策负责
弃聪明，求质朴
精心选择有效技术，绝不轻易抛弃
客户的客户才是你的客户！
事物发展总会出人意料
选择彼此间可协调工作的框架
着重强调项目的商业价值
不仅仅只控制代码，也要控制数据
偿还技术债务
不要急于求解
打造上手（zuhanden）的系统
找到并留住富有激情的问题解决者
软件并非真实的存在
学习新语言
没有永不过时的解决方案
用户接受度问题
清汤的重要启示
对*终用户而言，界面就是系统
优秀软件不是构建出来的，而是培育起来的
索引