开放源代码已经成为一些大型网站的基本原则。而在这些网站成长的过程中，一些优秀的实践经验和规则也出现在他们的结构中。本文旨在介绍一些在大型网站结构设计的过程中需要注意的关键问题以及实现目标的基础工作。 本文侧重于介绍网络系统，尽管一些准则在其他分布式系统中也是适用的。 1.1. web分布式系统的设计原则 搭建和运营一个可伸缩的web站点或者应用程序意味着什么？在原始层面上这仅仅是

Conceptual Architecture阶段        有经验的架构师不会一上来就关注如何定义“接口”，他们在大型系统架构设计的早期比较注重识别重大需求、特色需求、高风险需求，据此来设计概念架构。概念架构是对系统设计最初构想，就是把最关键的设计要素和交互机制确定下来，然后考虑具体技术的运用，设计出实际架构。概念架构应该抓大局、不拘小节。虽然概念架构都跳不出“架构=组件+交互”的基本定义

绪论        从本质上，架构设计是需求驱动的，而不是模型驱动的。但当很清楚需求却依然设计不出架构时，就说明“需求驱动的架构设计”的总结还“缺点什么”。架构设计是一门艺术，不可能把“一桶需求”倒进某台神奇的机器，然后等着架构设计自己被“加工生成”完毕，因此“需求驱动的架构设计”的总结给架构师的启发不够。那缺点儿什么呢？答案是“人的因素”、“架构师的因素”。        质疑意识，是架构师

在进行面向对象设计的时候不要受到过多OOP编程语言级细节的干扰，就是要有在设计之时将OOP细节忘却的能力。在不同层面思考，需要考虑不同的问题。OOD应更多地将精力放在职责的划分、变化点的隔离、交互机制的确定等问题上。不能忘却OOP级的编程细节，就无法真正在OOD层面上思考。        封装、继承、多态是OO的三大特性（笔者的理解是：封装是思想，继承是手段，多态是效果）。但是，不少人对继承的理

需求分析        那些没有经验的问题解决者们，几乎无一例外，都是去匆忙地寻找解决办法，而不是先给要解决的问题下定义。          什么是软件需求？什么是需求捕获、需求分析和系统分析？需求描述了系统必须满足的情况或提供的能力，它就可以是直接来自客户需要，也可以来自合同、标准、规范或其他有正规约束力的文档。需求的捕获是获取知识的过程，知识从无到有、从少到多。需求分析是挖掘和整理知识的

成功的架构设计 好的架构应当具有如下品质： 良好的模块化。每个模块职责明晰，模块之间松耦合，模块内部高聚合并合理地实现了信息隐藏。适应功能需求的变化，适应技术的变化。应该保持应用相关模块和领域通用模块的分离，技术平台相关模块和独立于具体技术的模块相分离，从而达到“隔离变化”的效果。对系统的动态运行有良好的规划。对数据的良好规划。明确、灵活的部署规则。        软件架构师的工作成功要

细化架构设计         多视图方法不仅仅是架构归档技术，更是指导我们进行架构设计的思维方法。将不同涉众关心的技术堆砌到一起，每个涉众都有可能看不懂了。另外，软件架构设计必须围绕“如何构建软件”制定多方面的设计决策，可能涉及的概念有很多：逻辑层（Layer）、物理层（Tier）、子系统、模块、接口、进程、线程、消息、协议，等等。基于之前介绍的5视图的架构设计方法，是解决上述两个问题的卓有成效

领域建模        分析的另一种重要产品是领域模型，其目标是使负责该系统基本行为的所有核心类可视。        软件的核心是它为用户解决领域相关问题的能力。        模型的选择会影响最终产生的系统的灵活性和可重用性。        由内而外早就软件。忽视了领域模型这个“内”，而仅重视编写程序这个“外”，多半是要出问题的。在对象开发过程中一个很重要的原则就是：要设计软件，使得软件

软件架构视图        方法指导过程，过程包含步骤。        所谓软件架构就是关于如何构建软件的一些最重要的设计的决策，这些决策往往是围绕将系统分为哪些部分、各部分之间如何交互展开的。不同的涉众看待软件架构的视角是不同的。软件架构是抽象的概念，所以在软件架构概念与实践之间，似乎存在某种“鸿沟”——即缺失某种概念，而这种概念可以“链接”软件架构的概念和实际的开发实际的需要，为不同涉众理

架构的概念        在软件行业，架构的概念一直没有一个完整、统一的定义，软件架构的概念分为主要量大派别：组成派和决策派。组成派认为软件架构是：软件系统的架构将系统描述为计算组件及组件之间的交互，“组件”是广泛意义上的元素，并不是指具体的技术组件。组成派的定义关注架构实践中的客体——软件，以及软件本身为描述对象；另外分析了软件的组成，即软件由承担不同计算任务的组成组件，这些组件通过相互交互完

MVC（模型—视图—控制器）模式 MVC将用户接口问题分割为三个截然不同的部分：模型、视图和控制器。模型存储应用的状态。视图解释模型中的数据并将它展示给用户。最后控制器处理用户的输入。 因为表示层是请求驱动的，所以“用户”可以是任意请求的发起者。控制器处理该请求。模型就是业务数据，而视图就是最终发生的应答。控制器是与请求发生联系的起点。控制器就是一个主管，首先规划要做哪些更新和要显

如今很多的公司的IT部门仍然认为招聘一个资深的程序员，他同样也能承担软件架构师的角色。 资深程序员对整个软件生命周期很了解，他们可以经过培训成为架构师，但他们不等同于架构师。一个软件架构师首要的和最重要的是他的远见。如果一个架构师拥有一些软件开发经验，那会更好，但大多时候，他们面对的是一个多语言的复杂环境。在第一行代码开始编写之前，架构师需要制定出业务需求如何转变成解决方案。这不仅仅需要业务

转一篇AWS设计运维的经验总结，原文地址：https://amazonaws-china.com/cn/blogs/china/10-lessons-from-10-years-of-aws/?spm=a1zb6.8232479.detailFloor.3.381812d7Qfyvul 作者Werner Vogels发布于 2016年3月14日 10 Lessons from 10 ...