怎样做软件架构

软件架构来源于我们对现实世界的理解、抽象和建模，是现世界中各种事物、流程在虚拟世界中的映射。一般来说，架构的需求来源于两部分：功能需求和非功能需求。功能需求就是用户能够直接感知到的业务功能，例如一个销售管理功能。非功能需求包含了各种约束和质量要求，例如开发语言、团队技能水平、性能、可靠性要求等。一个架构是由功能需求和非功能需求共同决定的，架构的复杂程度取决于功能需求的复杂程度，也取决于非功能需求，特别是质量需求。例如做一个简单的购物网站是比较容易的，可能1个人1个月就可以实现，但是如果做一个同样功能的，但是要共1亿人使用的购物网站，就需要一个多人的团队工作半年以上。对用户而言，购物体验并没有什么差异，但是大量的工作耗费在性能、高可用、安全等质量需求上。在华为，我们把质量需求统一叫做DFX（difinition for x, for example, difinition for performance）.

所以我的软件架构的大致步骤如下：

1.收集用户和产品的需求，包括显式的业务需求和隐式的非功能需求。

2.和业务专家、产品经理进行充分的讨论，对业务对象和流程进行抽象。这是很关键的环节，抽象的水平直接决定了架构的复杂程度和泛化能力。我一般采用DDD的思想来对业务进行建模。

3.考虑各种非功能需求，例如高可用，一般我个人喜欢全对等集群，不仅可以提升高可用，还可以根据性能要求进行水平扩展和收缩。

4.对架构中各种关键技术进行研究和选型

5.输出架构结果，我喜欢用5张视图来描述我的架构：逻辑视图、开发视图、运行视图、部署视图、数据视图。逻辑视图主要包含了各种功能模块和逻辑关系，领域对象和相互关系。开发视图主要包含开发人员从工程角度的各种规范定义，例如maven工程中的module和相互依赖关系。运行视图主要描述软件运行过程中，各功能模块之间的协调关系，例如当集群中一个节点故障时，相关服务如何进行故障恢复。部署视图描述了服务模块的部署要求，部署方式等信息。数据视图主要是描述数据的存储结构，如果是关系数据库，一般是主要的表名、字段名、类型、主键等信息，还有表之间的依赖关系。

一个高明的架构师，还需要考虑各种约束信息，例如团队人员技能水平，法律法规等。我在中恒的时候就犯过一个错误，我但是选择使用jstorm来进行实时数据处理，但是一开始由于负责的开发人员技能很低，出现了很多问题，一直到近期，等到人员技能提升了之后，才比较好的解决了问题。如果我在一开始架构的时候就考虑了这个问题，应该能够做更好的技术决策。对于法律法规的遵循也很重要，我以前在华为工作的时候，由于软件会售卖到伊朗、伊拉克等美国制裁的国家，我们在做软件架构时，必须要遵循塞班斯法案，例如要能够替换oracle数据库，因为oracle数据库是禁止出售给这些国家的。

以上是对这些年架构设计工作的一些简单总结。