最简单清晰的架构设计相关的介绍文档讲解.docx

1、什么是架构设计“架构设计是人们对一个结构内的元素及元素间关系的一种主观映射的产物。架构设计是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。” 来自百度百科。资料中的定义是准确、完备和书面化的，仍然很难理解架构设计的本质。通俗的描述，架构设计就像是小学考试中解答应用题的过程，但是解决的问 题更复杂，构思设计的过程更庞大，解题的工作量更大。2、项目的质量指标: 功能，性能和扩展性 软件开发的最终目标是使用代码去实现抽象的业务逻辑，可以从3个方面衡量：功能，性能和扩展性。（1）功能:功能目标是应用的基本要求，如果不能实现既定的功能逻辑，应用就失去了存在的意义，因此实现产品需求是应用的基本的目标。（2）性能:在基本的功能之上，会有一些性能的要求，但是很少有产品经理或者用户能提前提出这样的要求，因此架构师要有丰富的经验去发现和解决(或者为未来提升性能做准备)性能问题。性能的主要衡量有：单次请求的相应时间，单实例请求并发数，服务最大并发量等。（3）扩展性:目前互联网应用的开发模式:快速响应，迭代开发；提出需求，快速相应，尽快上线，是骡子是马拉出来溜溜。所以这就要求系统的架构设计要更好的响应新的需求和需求变更。3、架构设计的主要过程3年多来，数个项目的架构经验，我自己的架构设计过程是 : 确定问题域，数据建模，模块划分，关键流程描述，技术选型，代码实现，验收测试3.1、确定问题域记得小学考试后拿到老师改过的卷子，对着一个个的大红叉都会懊恼：”哎，又看错题目了“。错误的方向危害大于错误的方法，没有找对方向，项目就会南辕北辙， 远远偏离目标。来自产品经理或者用户的需求描述就是我们的问题域，但是来自于产品经理的需求描述会比较全面，内容也很多，来自用户比较简单，相对比较模 糊。比如电商项目的需求文档会非常大，拿到一个几十上百页的需求文档(有程序员拍砖说，我家的产品只一段话”像XXX网站的功能copy一下吧”，哈哈) 时，往往不知道从何处下手，所以我们要从繁杂的问题域中找到关键问题。a、用户可以在我们的网站上购买XXX商品。从a条出发，又延伸出来几个问题:b、用户访问:用户登录，注册c、商品来源:商品的管理，增删改查等d、交易的过程:订单的管理等从d交易出发，又能延伸出来e、用户付钱:支付f、商家配送:收货地址，配送流程不断的展开问题域，就可以把整个流程转起来。当然实际应用的时候我们不会把所有的问题域都总结出来，确定了关键问题就可以开始数据建模了。上面我们分析的是功能问题域，这会也需要确定一下性能和扩展性的问题域。性能的问题域应该是针对关键路径确定的，比如商品浏览，订单创建，订单支付等。针对于这些关键路径问题，可以定义一些问题域，比如单实例支持1000pv/秒商品浏览，100单/秒的订单提交等。扩展性是最难把握的，因为每个人经历不同，针对同样的项目会对未来需求有不同的预期，因此怎么把握当前的功能和未来的变化，如何平衡性能和扩展的关系，是架 构师设计的关键。以我的的经验来看，扩展把我关键问题，优先满足关键问题的性能，确定最小功能集。确定最小功能集的优势可以快速实现，快速验证需求的准确 性，每次需求开发都完成最小和最关键的需求。设计的时候要满足一些思想和原则，OOP(面向对象设计)原则:单一职责原则；开放闭合原则；里氏替换原则；依赖倒置原则；接口隔离原则;数据库设计三范式等等。扩展的问题域也可以参考友商或者与有经验的产品运营沟通，大致了解存在的扩展 性。电商项目可能会有:抢购，预定，团购等业务都是电商的一些扩展需求。3.2、数据建模确定了问题域就可以开始答题了，确定数据模型。大部分的应用基本使用的仍然是关系型数据库，所以我们针对问题域先创建数据表，当然也存在一些项目使用 NoSQL存储或者不持久化数据，这里确定的就是问题域的实体类。3.1中描述的问题域每个名称都是一个数据表(或者实体对象)，用户，商品，订单，支付 流水，收货地址，配送单。我比较喜欢使用powerdesigner做数据库模型，可以直观的看到表结构，方便修改，可以生成大部分DB的DDL SQL。为上面找出的名词(实体结构)创建表结构，然后根据产品需求文档一条一条的阅读判断，当前表结构是否可以满足需求，如果不能满足，在表中添加列或 者添加新的表来满足此需求，不断的去丰富表结构直到完全满足需求。当然在建模的过程中也会调整原来的表结构，毕竟不断的增加需求，会引起数据模型的变化， 所以最初建立的肯定不完整，不断调整直到满足所有需求。数据建模时的几个心得:a、数据表包含自增id,创建时间createTime,更新时间updateTime和版本号version自增的id:主键，根据id查询或者更新时，速度毕竟快。createTime和updateTime记录创建时间和最后的更新时间