怎样做软件架构

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

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

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

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

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

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

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

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

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

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180702G0CC5M00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券