初识产品架构设计

释放双眼,带上耳机,听听看~!

一直以来,总是觉得产品技术团队中的架构师是非常牛X的,尤其现在的互联网电商公司的系统复杂度那么高、业务那么复杂、新技术层出不穷,总是寄希望于架构师能够给出合理且可行的方案,相信很多朋友也都这么想,本篇就总结下最近的学习的内容,希望对架构有一个简单的认识。

初识产品架构设计

架构

参加过各种产品、技术大会的人都知道,演讲者的文稿中都会展现出产品架构图、系统架构图、组织架构图,有的是自顶向下,有的自左向右,有的自内而外,虽然表现形式不同,但是核心目的就是让相关人能够清楚的了解到其包含什么、应用了什么技术、相互间有什么逻辑或关联,如下面的图(来源网上)所示。

初识产品架构设计

图1

初识产品架构设计

图2

初识产品架构设计

图3

什么是架构

根据产品或项目需求,对于要实现的系统或产品进行边界范围的界定,并对目标系统按某个原则的进行切分。

切分的原则包括业务、产品和技术,要便于不同的角色,对切分出来的部分,并行或串行开展工作。

对于已经切分或规划的各个组成部分,建立沟通机制,促使其通信顺畅,使得这些部分之间能够进行有机的联系,合并组装成为一个整体,完成目标系统的所有工作。

架构设计目标

架构的目的就是解决产品、系统复杂度,结合有限的资源、有限的时间,完成项目目标,这里要结合实际的项目去考虑。

虽然架构设计很重要,但是做了架构设计并不一定提升开发效率,也不是每个产品或系统都要做架构设计的,对于系统架构一般考虑高性能、高可用、可扩展三大指标,但不同的时间点,不同的问题要有不同的解决方案,不应该小题大做,事得其反。

  1. 识别系统的复杂度,然后针对复杂点进行架构设计
  2. 不是面面俱到,不需要每个架构都具备高性能、高可用、高扩展的特点,主要是识别出复杂点然后有针对性的解决问题。
  3. 理解每个架构方案背后所需要的解决复杂点,然后才能对比自己的业务复杂点,参考复杂点相似的方案。

架构设计的难点在于取舍,架构是随着业务发展一点点演化完善起来的,软件架构从最初的结构化程序设计,到面向对象的开发思想,再到目前各种软件架构的技术框架,系统从单机到多机互联,再到目前的分布式计算,客户端从PC到手机,再到现在各种移动设备,复杂度成指数级增加,所以降低产品业务或软件系统的复杂度,复杂问题简单化应该是架构的目标。

架构设计的原则

架构设计没有像编程语言那样的语法进行约束,更多的时候是面对多种可能性的选择。

1.合适原则:合适优于业界领先

鞋合不合脚,只有脚知道,最新的技术并不一定是最好的,BAT等大厂应用的框架不一定适合你,竞品公司上线了社区团购项目并不能证明你也能上,公司的发展阶段不同、系统建设基础不同、人员水平不同,要选择相对合适的方案才是最好的选择。

譬如说数据核对平台,在基础数据层面的核对都没有保证的情况下,就采用复杂的规则引擎技术,引入大数据技术,消息队列等,真的适合吗?保证业务的快速发展,快速响应变化是比较重要的。

2.简单原则:简单优于复杂

对于中小型公司,资源有限,能简单尽量简单,曾参与过一个社区团的系统规划,当时的产品有3个,研发有十几人(分前、后端),对于比较重要的供应链后台就采取了尽可能简化的规划,包括商品、采购、销售、OMS、财务几个核心系统,数据存储上也没有进行严格的业务拆分(虽然比分库分表简单,但拆分后有些逻辑只能用程序代码实现,无法Join),以提升研发效率。

在详细设计时,尽量降低逻辑的复杂性,服务组件设计上也进行了相应的控制,如果结构复杂,组件越多,就越有可能其中某个组件出现故障,某个组件改动会影响关联的所有组件,定位问题困难。

以结果为导向进行架构方案的设计应该是必要的,简单有效解决了问题正是架构设计的目标:复杂度。

3.演化原则:演化优于一步实现

高性能、高可用、可扩展、安全性、低成本是架构设计考虑的几个方面,但是有些时候只能兼顾,要随着业务的发展不断演化。

软件系统如此,产品规划也是一样的,在互联网电商公司工作多年,系统的合并与拆分是永远的工作,合久必分、分久必合。

在当前的时期内能够满足当前的业务需求,然后经过不断迭代,保留好的,修复有缺陷的,改正错误的,去掉无用的,当业务变化时,架构要扩展、重构、甚至重写,这就是重生。

架构设计流程

初识产品架构设计

识别复杂度

在加入一个公司时,你会发现好多都是外表光鲜,内部一团乱(系统多、业务流程复杂、组织多、效率低),这是非常正常的情况。
架构设计的目的就是识别复杂度,降低复杂度。

  • 对于产品系统的复杂度,个人倾向于可以以信息流为主线,资金流和商品流为辅助进行,以主流程上的各个关键环节为突破点,逐步识别。
  • 对于软件系统的复杂度,从系统间的关联度开始,了解其关键模块、关键数据及系统间的通讯,重关注重叠的功能或模块,看看哪些是重复的或孤立的,区分出核心系统或模块。
  • 将业务流程与软件系统结合进一步识别、区分,针对实际项目、软件产品进行复杂度的划分。
  • 非功能性的复杂度识别,这些包括性能、技术、未来的发展等等,这些隐性的需求是架构设计时的重点

当然,以上应该在当前项目产品的范围内,不要过度但绝不能少:)。

备选方案

  • 对于备选方案以3个为最佳,1个太少,5个以上又太多,避免在评审时没有侧重点。
  • 备选方案不是选择设计最优的,而是选择最合适的方案,也是正符合了架构设计的最简单原则。
  • 备选方案间要有明显的差异性,这样比较容易确定,同时备选方案也不能太详细,避免耗费过多的时间成本。
  • 对于技术应用上,要不局限于已经熟悉的技术,要能够跳出去,打破经验主义。

工作中接触过不同公司的架构师,多数人似乎都是经验为主,往往套用其呆过的公司的方案,总是觉得并非我想象中的架构师。

评估和选择备选方案

有几种风格即最简派(以最简单的备选方案为主)、最牛派(选择最好的,如最新的技术、目前最流行的产品)、最熟派(选择自己最熟悉的)、领导派(由领导去选择,好与坏由领导承担),这里没有对与错。

评估时可以从性能、可用性、硬软成本、项目投入时间、复杂度、安全性、可扩展性、人员学习成本等多个维度进行评估,可以设置权重,但但这里要遵循“合适原则”与“简单原则”,同时要按照“演化在的则”可以不断完善。

详细设计

根据近几年的工作经验,很多公司都在推行敏捷项目的管理方式,有些产品文档替代了开发设计文档,其实这违背了敏捷的原则。

对于架构设计时,确定了备选方案后,也要进行其详细设计,包括产品架构和软件系统架构。在详细设计过程中可能会推翻最初的备选方案而面临着二次选择。

详细设计应该是由架构师完成的,而不是由其指导产品经理或研发人员去完成的,但这个不同于产品PRD文档或开发设计文档,它还应该是指导性的,有一定细化方案的内容。

实际的工作中,很多都是有模糊的架构设计、而缺少详细设计,对于架构师提出的方案你挑不出问题,但是落地却又很难,所以详细设计的目的就落地。

写在最后

总结一下,架构是解决复杂度,它遵循3个原则:合适、简单、演化,要经过识别复杂度、考虑备选方案、选择备选方案和详细设计4个流程来进行。

了解这些内容对于产品、研发是有帮助的,可以让我们在沟通过程中更顺畅,清楚一些点,方便判断和选择。

给TA买糖
共{{data.count}}人
人已赞赏
产品设计

B端协同办公中的“开放平台”如何设计

2020-11-18 13:12:21

产品设计

问卷调研(上):如何搞定问卷调研

2020-11-18 15:17:25

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
搜索