架构工作内容.md
概述
架构定义
graph LR
ae[Architecture Element]
ie[Inter-Element Ralationship]
a[Architecture]
system[System]
ad[Architectural Description]
stakeholder[Stakeholder]
view[View]
vp[Viewpoint]
concert[Concert]
ie --->|relates| ae
a --> ae
a --->|comprises| ie
system ---> |has an|a
system -->|addresses the needs of| stakeholder
a --> ad
ad --->|documents architecture for| stakeholder
ad --> |comprises| view
view -->|conforms to| vp -->|addresses| concert
stakeholder --> |has| concert
- 每个系统都有一个架构
- 架构由架构元素以及相互之间的关系构成
- 系统是为了满足利益相关者（stakeholder）的需求而构建的
- 利益相关者都有自己的关注点（concerns）
- 架构由架构文档描述
- 架构文档描述了一系列的架构视角
- 每个视角都解决并且对应到利益相关者的关注点。
首要任务
架构系统前，架构师的首要任务是尽最大可能找出所有利益相关者，业务方，产品经理，客户 / 用户，开发经理，工程师，项目经理，测试人员，运维人员，产品运营人员等等都有可能是利益相关者，架构师要充分和利益相关者沟通，深入理解他们的关注点和痛点，并出架构解决这些关注点。架构师常犯错误是漏掉重要的利益相关者，沟通不充分，都会造成架构有欠缺，不能满足利益相关者的需求。利益相关者的关注点是有可能冲突的，比如管理层（可管理性）vs 技术方（性能），业务方（多快好省）vs 技术方（可靠稳定），这需要架构师去灵活平衡，如何平衡体现了架构师的水平和价值。
abilities
架构的第二点定义是说架构主要关注非功能性需求（non-functional requirements），即所谓的 -abilities
- easy to separate -> Autonomy
- easy to understand -> Understandability
- easy to extend -> Extensibility
- easy to change -> Changeability
- easy to replace -> Replaceability
- easy to deploy -> Deployability
- easy to scale -> Scalability
- easy to recover -> Resilience
- easy to connect -> Uniform interface
- easy to afford -> Cost-efficiency
这个是 slideshare 一个 ppt 里头截取的，两个图都是列出了架构的非功能性关注点；关于架构的水平该如何衡量，去年我看到一句话，对我影响很大。
Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.
翻译为中文就是，架构表示对一个系统的成型起关键作用的设计决策，架构定系统基本就成型了，这里的关键性可以由变化的成本来决定。这句话是 Grady Booch 说的，他是 UML 的创始人之一。
进一步展开讲，架构的目标是用于管理复杂性、易变性和不确定性，以确保在长期的系统演化过程中，一部分架构的变化不会对架构的其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷，让应用的易变部分能够频繁地变化，对应用的其它部分的影响尽可能的小。
我刚入软件开发这个行业之初，谈的架构主要是性能，高可用等等。现在，见过无数遗留系统，特别是国内企业 IT 的现状，无数高耦合的遗留系统，不良的架构像手铐一样牢牢地限制住业务，升级替换成本非常巨大， 所以我更加关注可理解，可维护性，可扩展性，成本 。我想补充一句，创业公司创业之初获得好的架构师或技术 CTO 非常重要。
架构的迭代和演化性
RUP，统一软件过程的理念。RUP 的理念对我的架构有很深的影响，RUP 总结起来就是三个特点：
用例和风险驱动 Use Case and risk driven
架构中心 Architecture centric
迭代和增量 Iterative and incremental
RUP 很注重架构，提倡以架构和风险驱动，项目开始一定要做端到端的原型（prototype）；通过压测验证架构可行性，然后在原型基础上持续迭代和增量式开发，开发 -> 测试 -> 调整架构 -> 开发，循环，如下图所示：
graph LR
architecture --> code & test
test --> architecture & code
code --> architecture & test
从上图可以看出架构师要尽可能写代码，做测试，纸上谈兵式做架构而后丢给团队的作法非常不靠谱（除非是已经非常清晰成熟的领域）。另外，做技术架构的都有点完美主义倾向，一开始往往喜欢求大求全，忽视架构的演化和迭代性，这种倾向易造产品和用户之间不能形成有效快速的反馈，产品不满足最终用户需求。
第一个图是讲最小可用产品（Minimum Viable Product， MVP）理念，做出最小可用产品，尽快丢给用户试用，快速获取客户反馈，在此基础上不断迭代和演化架构和产品。第二个图是过度工程（Over Engineering）的问题，其实也是讲产品架构和用户之间没有形成有效的反馈闭环，架构师想的和客户想的不在一个方向上，通过最小可用产品，快速迭代反馈的策略，可以避免这种问题。注意，在系统真正地投入生产使用之前，再好的架构都只是假设，产品越晚被使用者使用，失败的成本和风险就越高，而小步行进，通过MVP快速实验，获取客户反馈，迭代演化产品，能有效地减少失败的成本和风险。
另外，多年的经验告诉我，架构，平台不是买来的，也不是用一个开源就能获得的，也不是设计出来，而是长期演化才能落地生根的。
构建闭环反馈架构
必要性
- 持续改进与优化：通过实时反馈，开发团队可以快速发现问题，改进架构和代码质量，从而提高软件的稳定性和性能。
- 加快交付周期：反馈机制使团队能够在每个迭代中获取用户和系统的实时信息，确保软件能够适应业务需求的快速变化，缩短交付周期。
- 降低风险：闭环反馈可以有效减少未知风险，提早发现潜在问题，避免上线后产生重大故障或代价高昂的修复。
- 自动化与高效协作：结合自动化工具（如持续集成、持续交付），反馈机制有助于优化整个开发到交付的工作流程，促进开发、测试、运维之间的高效协作，提升软件交付效率。
- 数据驱动决策：闭环反馈提供了丰富的数据和洞察，帮助团队在软件开发和交付过程中做出更精确的决策，优化资源配置、提高系统弹性，并根据实际用户行为调整功能。
通过这些反馈回路，架构师能够确保软件交付过程的高效、可靠与灵活性，并更好地满足不断变化的市场需求。
系统思维
第一条道路，系统思维，开发驱动的组织机体，其能力不是制作软件，而是持续的交付客户价值，架构师需要有全局视角和系统思维（System Thinking），深入理解整个价值交付链，从业务需求、研发、测试、集成，到部署运维，这条价值链的效率并不依赖于单个或者几个环节，局部优化的结果往往是全局受损，架构师要站在系统高度去优化整个价值交付链，让企业和客户之间形成快速和高效的价值传递。
第二条道路，强化反馈环，任何过程改进的目标都是加强和缩短反馈环。刚入行的工程师，也是中国学生的普遍问题，就是生产运维意识不足（监控是系统反馈的重要环节）。有两句号这样讲的：
no measurement, no improvement 没有测量，就没有改进和提升
What your measure is what you get 你测量什么，就得到什么
没有监控或者监控不完善的系统相当于裸奔，开车上高速无仪表盘。有一篇很不错的关于测量驱动开发的文章，在 InfoQ 上的，向大家推荐：
http://www.infoq.com/cn/articles/metrics-driven-development
这篇文章提出了度量驱动开发的理念，即所谓 MDD，在系统，应用和业务三个层次，通过三级监控，构建三个反馈环，在监控测量基础上持续改进系统和架构，我最近也在参考这个理念设计一个电商平台的技术架构，见下图：
这是一个电商平台的架构，整个体现了闭环架构的思想，右侧是整个平台的反馈监控环节。具体如下：
系统层监控计算网络存储，构建系统层的反馈环
应用服务层，监控业务、应用、服务，甚至整个研发流程，构建应用和服务层的反馈环
客户体验层，监控端用户和分析网站用户的行为，构建和客户的反馈环
下面这个图展示了系统提升和改进的一般方法：
收集 -> 测量 -> 调整 -> 闭环重复，在有测量数据和反馈的基础上，系统、应用、流程和客户体验才有可能获得持续的提升和改善，否则没有数据的所谓改进只能靠拍脑袋或者说猜测。
第三条道路，鼓励勇于承担责任，冒险试错和持续提升的文化。这点是最难的，一般和企业人才密度有关。工具，技术，流程只是一个公司的冰山浮出水面的部分，而真正对企业效能影响大的则是冰山水下的部分，即企业的人和文化，架构师作为技术和架构的布道者，有责任义务鼓励和推动试错文化。
架构师要深入领会这三条道路，关注整个价值交付链的效率，关注每个环节的闭环反馈，鼓励和推动公司的试错文化，打造全系统的闭环架构（Architecting for closed loop feedback），提升整个系统效能。下图的 DevOps 和每日交付是每一个互联网系统架构师的梦想和努力的方向。
架构和组织文化关系
将单块架构解耦成微服务，每个团队开发，测试和发布自己负责的微服务，互不干扰，系统效率得到提升。
可见，组织和系统架构之间有一个映射关系（1 ~ 1 mapping），两者不对齐就会出各种各样的问题，一方面，如果你的组织结构和文化结构不支持，你也无法成功建立高效的系统架构，例如集中式和严格职能（业务, Dev, QA, Deployment, Ops）的企业，很难推行微服务和 DevOps，推行 Docker/PaaS 平台也会比较困难，这样的组织职能之间都倾向于局部优化（local optimization），无法形成有效的合作和闭环。
反过来也是成立的，如果你的系统设计或者架构不支持，那么你就无法成功建立一个有效的组织；作为系统架构师，一定要深入领会康威定律，设计系统架构之前，先看清组织结构，也要看组织文化（民主合作式，集权式，丛林法则式，人才密度），再根据情况调整系统架构或者组织架构。