• 软件架构应关心的若干要素


          本篇文章主要分析,架构师在设计系统架构时,应关心哪些关键要素?

    一  业务场景


           A公司是一家服装公司,主要提供服装一体化服务(服装设计,服装销售,售后服务等),该公司主要通过淘宝,天猫,京东等平台进行销售,由于公司

    良好的服装质量,高效的服务水平和良好的信誉等,使得公司的销售量不断地增长,到了第五年,公司的销售呈现指数型增长....,为了迎合指数型的业务需

    求,公司高层决定使用互联网技术来迎合指数型的业务需求。

            该项目由CTO全程负责,并向CEO汇报,CTO指定小张为该项目业务负责人,小红为该项目技术负责人,他们两人定期向CTO汇报。其中,CTO主要负

    责系统的系统架构,项目管理,团队组建,关键业务沟通等工作,小张主要负责业务相关的事,如需求调研,需求文档编写等,小红主要负责项目落地开发,

    如核心模块开发,及时解决团队开发出现的技术性问题。

            如此,CTO做出了如下的业务架构,该项目命名为:线上仓储系统(OnlineWMS)

           (1)通过线上平台提供的接口,抓取用户订单

           (2)将抓取的订单存储到仓储系统

           (3)将订单相关信息传递给SAP(可以理解为财务系统)

           (4)当货物发送后,在WMS系统上,通过物流接口查询订单状态(发送,未发送,已收货,退货等)

    二   架构师应关心的若干要素


     1.明确系统功能(what)

    在业务架构中,系统架构师一定要非常了解且明确系统要解决的核心业务,在设计前,建议考虑如下问题:

    项目需求是什么?

    项目需求是基于什么背景下提出的?

    项目需求的核心业务是什么?

    项目需求的难点和痛点是什么?

    ....

    在充分考虑如上问题后,就是问题答案的寻找和求证过程:

    答案寻找?

    如上系列问题,均可在需求文档中找到,因为一般情况,需求文档都会有详细描述,需求文档的来源一般经过几个阶段:

    需求提出=》需求调研=》需求初稿=》需求评审=》需求修改=》需求定稿

    答案求证?

    系统架构师在充分研读需求文档后,对需求基本有所了解,然而这些所谓的了解,是需要与需求提出者,需求撰写者等关键人物确认的

    确认的,这个过程也叫答案的求证过程,只有该过程确定后,方可进行下一环节。

    2.定义系统边界(Scope)

    在充分明确需求后,就要定义系统边界了,首先来了解一下,什么叫系统边界。

    系统边界:指本次项目由哪些系统构成(或子系统构成)。

    CTO为OnlineWMS系统定义了四个边界:线上接口(订单的来源),物流接口(订单状态查询),WMS系统(订单管理,衣物存储等),SAP系统

    (财务相关)

     很容易看出,这几个边界定义还是比较明显的,职责分工明确,无重叠业务。

     

    3.定义系统之间的交互方式

    CTO为OnlineWMS系统定义了四个边界,且这四个边界的交互方式是以接口的方式进行的。

    4.接口设计规范

    关于接口设计规范,请参考我的另一篇文章  如何设计一个良好的接口

    5.系统难点

    该系统,从线上抓单,且将订单及时地存储到WMS系统是一大难点和挑战点,尤其在双十一,双十二等高峰时段,成千上万的高并发量,

    10w-1000w的订单量等都完全有可能导致系统崩溃。然而,该难点却有很多可以捕捉的特点,归结如下:

    (1)存在高并发量特征

    (2)存在大规模订单特征

    (3)存在系统响应及时特征

    (4)存在高并发、大规模订单集中于某个时间段,而非长时间(如1年)特征

    .......

    6.业务模块与非业务模块拆分

    该系统中,存在业务模块与非业务模块,需要进行拆分,如非业务模块授权管理、日志记录等需要从业务中拆分开发来,可以采用AOP技术

    实现,如Spring AOP,AspectJ等。

    7.模块解耦

    该系统中,模块之间存在必要的依赖关系,为了尽可能的降低这些依赖关系,可以采用DI(依赖注入技术)来解决,如Spring框的DI。

    8.技术选型

    涉及到前端框架,后端框架,ORM框架等。

    在选择框架时,尽量选择主流且被广泛使用的框架,尽量不要选择不太主流或太新的框架。

    在框架组合时,防止过大,也防止过小,如SSH,SSM,SpringBoot+SpringCloud+Redis+Mongo+MQ+Dubbo等,要根据具体的业务场景来选择。

    9.开发团队

    在组建团队时,要充分考虑风险,如团队人员突然离职造成项目延误等风险,建议采用职能组织架构结构来组建团队。如一个技术开发经理,2个高级开发,3个中级,4个初级等,

    这样搭配的好处是,当技术开发经理突然离职(一般技术开发经理很少离职),2个高级开发可以顶替上去;若有一个高级开发离职,两个中级可以顶替上去....如此,就算某个人离职,

    对项目影响都不会太大。

    10.项目管控

    管理项目计划,项目进度,开发团队人员情绪、处理开发技术问题等。

    三  版权区


    •    转载博客,必须注明博客出处
    •    博主网址:http://www.cnblogs.com/wangjiming/
    •    如您有新想法,欢迎提出,邮箱:2098469527@qq.com
    •   专业.NET之家技术QQ群:490539956
    •   专业化Java之家QQ群:924412846
    •   有问必答QQ群:2098469527
    •   一对一技术辅导:2098469527
  • 相关阅读:
    【译】使用自定义ViewHelper来简化Asp.net MVC view的开发part5(完)
    【译】使用自定义ViewHelper来简化Asp.net MVC view的开发part1
    【译】使用自定义ViewHelper来简化Asp.net MVC view的开发part3
    开发者分享在PC上制作iOS游戏的经验(上)
    dpi和ppi是什么意思
    Go语言
    逆向思维魔兽世界封包分析(2)
    关于手机游戏的部分情况调查
    《Android Dev Guide》系列教程1:什么是Android?
    拼包函数及网络封包的异常处理(含代码)
  • 原文地址:https://www.cnblogs.com/wangjiming/p/10437334.html
Copyright © 2020-2023  润新知