1引言
在标题的取名上,不敢说颇费心机,也算得上花费了一点功夫的。首先想到的是“架构设计过程”,又觉得是不是太大了,因为例子比较局部,不是很完整。叫做“结构变化过程”可能更好点。但是又怕名字取的小气了,进来的人少,参与讨论的就更少了,最终还是取了这个有点忽悠人的标题“架构演进”。
今天的这个架构演进,使用系统中一个局部的实例进行推导和演进,一起来观察一下,架构是如何不满足需求的?架构如何演进?更好的架构应该具备哪些条件?有没有更好的呢?
业务场景
图1 业务场景图
从上图可以看出,就是一个电子商务网站常见的支付、支付的后续处理,这样一个业务场景。支持多种支付方式,目前包括银联、支付宝,还有平台账户。平台账户就是注册用户将资金存储在平台为用户建立并维护的一个账户里,购买平台的产品,可以使用平台账户中的资金进行支付。
2业务流程
-
首先用户选择商品。
-
下单,进行支付。
-
选择支付方式。
-
使用相应支付方式进行支付。第三方支付,会跳转到第三方的支付页面进行支付。
-
平台进行支付的后续处理,包括成功之后的修改状态等,还包括失败之后的记录标记等。
第三方的支付,在打开第三方支付界面的时候,会告诉它一个平台的回调地址,支付之后,通过回调地址接收第三方支付的结果,然后进行后续处理。使用平台账户支付,就直接进行后续处理就可以了。
当然,这其中还会有一些细节,不在我们的讨论范围。例如:使用平台账户进行支付,判断账户金额是否充足。使用第三方支付,是否记录第三方支付的完整过程,以及完整的支付流程。等等具体的业务细节均不在今天的讨论范围。
3初级架构-用存储过程搞定它
回调地址接收两个参数,一个是订单编号,一个是标志。标志说明是成功还是失败,或者是更加详细的信息。
配合一段C#代码,判断一下支付方式,然后给存储过程传递参数。这样写的话,上面的这个存储过程很容易就超过1k行了,相信大家也写过1k行以上的存储过程,也维护过这样的存储过程,知道个中的酸甜苦辣。
如果说那一天我们增加了一种支付方式,需要修改的地方包括哪些呢?
界面要修改,存储过程要打开修改,调用的C#代码要修改。真是有点麻烦,最主要的是容易改错了,误改了不应该动的地方才是最要命的。好吧,我们简单分离一下。每种支付方式一个存储过程,把对于支付方式的判断放在代码中,每种支付对应一个代码中的方法。这样需要增加一种的话,只要改改支付方式判断的代码,然后重新写一个存储过程,重新写一个方法调用一下新的存储过程就可以了。可是还有一个问题,更新订单状态好像大家都在做,如果哪一些还需要加一些大家都需要做的事情呢?或者说修改一些大家都需要做的事情的细节?又或者说某两个支付方式需要增加一个处理流程呢?打开存储过程,狂修改吧!!!!
存储过程有几个不便利的地方:
- 调试不方便
- 测试不方便
- 代码不能折叠,多了之后要拖动滚动条才能找得到
- 逻辑运算、大规模计算是存储过程的弱项
存储过程的优势至少也有一个,就是修改之后,马上可以见到效果。不用编译。
4中级架构-在代码中分离对每种信息的更新
之前的架构代码中有很多的重复地方,例如:对于订单信息的更新。如何把重复降低呢?降低重复也就集中了代码,集中了将来也好维护。而且把它分离出来,独立出来,好像更好点,在需要的地方调用就可以了。如果需要变更订单的更新细节,只要修改一下更新细节就可以了,不需要动支付的代码。减小犯错误的概率。
首先,将各种更新信息独立出来。
使用下面的方法进行支付的后续处理。
增加支付方式的话,新建一个HandleService类,写一些处理代码,然后在public void HandlePaymentResult(PaymentManner2 paymentManner, string orderSeqNo)方法的switch中增加一个case就可以了。
但是页面的可选支付方式还是写死了,没有动态的变化,支付方式是否可以动态配置呢?而且可以方便的测试呢?例如:虽然我还没有银联的接口,但是我想测试一些,银联支付之后平台的处理是否正确,该更新的信息是否都更新了呢?没有银联的接口,是不是就不能做了呢?有没有办法解决呢?
答案是:有。
还有就是上面的switch。。。case,好像会很长,也很丑,这个地方能否改进呢?很多人在学习了重构之后,会提出很多的方法来解决这个问题,我们再后面也一块来解决一下。
5高级架构-少用存储过程处理业务的灵活架构
我们的高级架构有几个目标
- 减少存储过程中的业务逻辑,让存储过程更加纯粹的做事,做它擅长的事情。
- 可以灵活的增加或者减少支付方式。达到在增加或者减少支付方式的时候,尽量少的修改代码,尽量减少依赖。减少支付对于支付方式的依赖,支付方式对于后续处理的依赖。
- 代码结构更加清晰。
为了达到上面的几个目标,计划独立几个部分。
- 支付方式的管理。
- 每一种支付方式的处理过程。这个在中级架构里面已经做的差不多了,这里会做的更好一点,抽象这个支付处理过程。
还有就是要隐藏支付方式和具体的支付方式处理过程映射代码。具体的支付方式指的是:银联或者是支付宝这种具体的一种支付方式。目的就是让对于支付订单的处理独立化,固定化,支持变化。
5.1支付方式的管理
通过FindAvailableManner方法获取支付方式。每种支付方式PaymentManner,都带有一个参数实体PaymentMannerParams,里面的UriOrFunction来决定是通过网页还是内部方法来支付,Uri就跳转到Uri就可以了,Function就调用FunctionName中的方法就可以了。支付的时候用下面的Pay先获取支付方式信息,然后根据每种支付方式的参数来决定具体的支付。
之前说的,如果银联还没有接口,或者接口暂时不能用了,想测试一下后续的处理,就可以将银联这种Manner的UriOrFunction设置为Function,现用内部的方法来测试后续的处理是否正确。等可以用的时候,在变更为Uri就可以了。
5.2支付过程的抽象
通过建立支付处理的接口,将支付处理的代码抽象成下面的样子。
这个处理的代码,原则来说以后都不需要修改了。后面要做的就是定义一种新的支付方式枚举量,然后实现IPaymentResultHandleService1 接口,写一些处理的代码就可以了。
5.3完整代码
6总结
类的依赖最好使用抽象,避免具体类的直接引用。
尽量不要再存储过程中处理业务,随着系统越做越大,你会越来越赞同我的说法。原因至少两点:1维护累死人,2数据库不擅长数值计算和处理。
职责单一,功能独立,代码分离。
分享到:
相关推荐
本课程基础篇主要目的是帮助初学者掌握基本的系统架构理念,通过实例和图示进行深入浅出的讲解,以期让更多的人能理解和运用架构知识。 首先,我们要理解什么是架构。Mary Shaw的观点指出,架构是计算组件及其交互...
服务端高并发分布式架构演进之路的知识点可以从以下几个方面来详细说明: 1. 基本概念介绍 - 分布式架构:在不同的服务器上部署系统各个部分,以提升系统伸缩性和可用性。 - 高可用性:系统或服务在各种情况下都...
其次,书中提到了架构的演进过程。随着技术的发展和业务需求的变化,软件架构也在不断演变。从早期的单体架构到现在的微服务架构,每种架构模式都有其适用场景和局限性。理解这些演进趋势有助于我们在面对不同项目时...
MySQL高可用架构演进是数据库领域中的一个重要话题,尤其是在企业级应用中,数据的稳定性、一致性和可访问性是至关重要的。MySQL作为广泛使用的开源关系型数据库管理系统,其高可用性设计是确保业务连续性和数据安全...
因此,简化业务模型复杂度,实现不同业务间的解耦,成为架构演进的主要目标。 为应对这些挑战,报告提出了领域驱动设计(DDD)作为核心策略。DDD强调通过领域模型来理解和表述业务规则,将复杂的业务逻辑转化为清晰...
藏经阁-微服务在云上的架构演进 微服务概要 ---------- 微服务是一种架构风格,它将应用程序拆分为多个小型、独立的服务,每个服务都可以独立开发、测试和部署。微服务架构的特点是:以产品功能划分服务、决策权...
Apache DolphinScheduler 架构演进与 Roadmap Apache DolphinScheduler 是一个分布式、易扩展并带有强大的可视化界面的大数据工作流调度系统。自 2021 年 03 月 18 日正式成为 Apache 顶级项目以来,Dolphin...
《豆瓣架构演进》这份学习资料深入探讨了互联网巨头豆瓣网在发展过程中其技术架构的迭代与优化。作为一家提供图书、电影、音乐等多领域信息分享与评价服务的平台,豆瓣的技术架构需要应对海量数据处理、高并发访问...
根据提供的信息,我们可以总结出以下关于“阿里云Redis技术架构演进”的详细知识点: ### 一、阿里云Redis概述 **阿里云Redis**是阿里云提供的一种基于内存的数据存储服务,支持多种数据结构,如字符串(Strings)...
此外,AWS良好架构框架还包含了一套通用设计原则,这些原则涵盖了容量规划、测试、自动化、架构演进、数据驱动以及系统改进等诸多方面。例如,停止猜测你的容量需求、用生产规模测试系统、自动化基础架构使实验更...
阿里异地多活与同城双活的架构演进 阿里异地多活与同城双活的架构演进是阿里巴巴高级技术专家唐K的分享,主要讲述了阿里巴巴异地多活和同城双活的架构演进历程、挑战和解决方案。 一、阿里异地多活的演进历程 ...
《架构演进:汽车之家架构分析》是一份深入探讨汽车之家平台架构发展的学习资料,它涵盖了从早期到现代的架构变迁过程,旨在为IT专业人士提供一个理解大型网站架构演进的实例。汽车之家作为国内知名的汽车行业信息...
《架构解密-从分布式到微服务》这本书深入探讨了现代IT系统的发展历程,从最初的单体架构到分布式系统,再到微服务架构的演进。本文将基于书中的内容,结合标签“架构解密”,详细阐述相关知识点。 一、分布式系统 ...
当谈论微服务在云上的架构演进时,我们需要考虑几个关键要素,包括服务发现与访问、数据存储与管理、自动化部署、监控与日志等。 服务发现与访问是微服务架构中的核心概念。在云环境中,服务实例可能会频繁变更其...
### 饿了么API-Gateway架构演进 #### 1. 背景 在2016年5月17日的饿货节期间,饿了么达到了每秒1.5万笔订单的峰值,这一巨大流量导致系统入口在活动开始后的前几秒就被打爆,不得不采取限流措施。由此产生了几个...
在大型网站的架构演进中,最初可能采用单体架构,所有功能模块都在同一台服务器上运行,通过JVM内部调用交互,数据库通过JDBC访问。随着流量增加,会面临单机负载告警,此时数据库与应用服务器分离,减轻单机压力。...