一个失败架构升级案例

架构师的核心能力-抽象能力 在做架构升级的时候,

升级开始:

升级过程:

结束:

虽然升级完了能很好的满足未来的需求,但是在升级的过程中一个需求可能要同时在新老链路里同时实现,风险和工作量加倍。


架构的核心是管理复杂度,架构师的核心能力是抽象能力,什么是抽象能力?抽象能力就是一种化繁为简的能力。何为化繁为简?就是把一种复杂的事情变得简单的能力,比如通过打比喻让别人很容易听明白你说的意思就是一种抽象能力。如何锻炼抽象能力?我觉得有三种方法,第一种是用归纳法找共性,从多个问题中找到共同的问题提炼通用解决方案,去其糟粕取其精华。第二种通过演绎法找关系,从多个问题中找关系,把多个问题串成一个问题,系统化解决问题!第三种是通过归纳法找特性。化繁为简需要不断的思考,不断的看清一件事的本质,这个事的解决方案越容易。

一、通过归纳法找共性

通过归纳法找共性有两种方法,分别是找需求的共性和找信息的共性

1.1 找需求的共性分期作为一个单一产品服务于海量亿级用户和全行业,但是各行业有很多的个性化需求,有限的技术资源不可能解决无限的行业个性化需求,所以必须对问题进行收敛,从一类需求中找到共性问题,找到最大交集然后求解。找需求的共性就是你收到一堆需求,你能分析出共同的需求是什么?比如用户说想吃香蕉、梨子、桔子和苹果等,那么共性的需求就是用户想吃水果。分期有商家贴息、部分贴息、第三方贴息和混合贴息等需求,共性需求就是灵活的贴息模式,然后基于这个共性的需求,推导出我们可以提供的技术服务或技术能力是什么,从而推导出系统架构,再比如各行业都想接入分期,但是都有些个性化的需求,那么我们是不是可以对个性化需求进行分类,提供几种标准的分期组件让各行业快速接入,比如小程序分期组件、H5版分期组件和JS版分期组件等。如果把这个问题再扩展下,作为技术要解决的问题也非常多且复杂,如果找共性需求,对所有技术问题进行收敛的话,可以收敛成三个基本需求,第一个是技术如何给业务带来护城河?第二个是技术如何给业务带来增量?第三个是技术如何保障业务安全运行?再延伸到经济活动,经济活动的本质或者核心需求是人类需求与服务供给的匹配,能交往和交流的人越多,匹配越容易匹配效率越高,人均GDP也越高,也就越富裕。

1.2 找信息的共性领域建模就是一种找信息共性的方法,领域建模首先就是要区分需求里哪些是变化的哪些是不变,把这个领域不变的信息沉淀成领域模型,基于领域模型做架构。分期在各个场景下可能衍生出不同的分期产品,如租房分期、汽车分期、家装分期和电商分期等,但其实共性都是通过组合额度、利率和还款方式等几要素产生不同的分期产品,比如电商分期额度较低、还款期限最长24个月,汽车分期则额度较高、还款期限可达3年。我们学习技术也是一样,所以技术的共性是什么,我觉得是TCP\IP等协议、语言基础、数据结构等基础技术,这些基础技术点你会发现几十年都不会变化。

二、通过演绎法找关系

通过演绎法找关系能让架构师更体系化的看一个问题。通过演绎法找关系可以分为找内部关系和找外部关系两种

2.1 找内部关系内部关系就是找到业务的生命周期和系统内部的主链路,分期业务虽然支持各种场景的个性化需求,但是系统内主链路和生命周期就一个,也很少发生变化,比如分期业务的生命周期是分期创建-分期失败-分期成功-分期支付关闭,他们的关系是从分期支付单创建到支付成功或支付失败,从支付成功到退款,最后到支付关闭。系统内部主流程包括前置鉴权、支付咨询、支付和退款等。找关系的的另外一个作用就是你看到一堆需求,你能看出这些需求彼此的关系是什么,通过这些关系去分析未来需求的趋势,是偏分期线下的需求更多,还是偏分期线上的需求更多,为啥是分期线下的需求会逐渐多起来,那么未来是不是要围绕着分期线下进行架构升级,通过对分期未来的趋势的判断做架构升级,把未来很多不确定性的事情变得逐渐有确定性。

2.2 找外部关系外部关系梳理清楚架构的边界,什么做什么不做,什么是本领域的核心服务,这些服务提供给谁使用,我们需要依赖其他领域的核心服务有哪些。为什么理清楚架构边界能够化繁为简?因为架构边界类似一个架构标准,大家遵循统一的标准沟通效率和沟通复杂度就会降低,否则每个需求都要讨论这个功能做在哪个系统?为啥要放在这个系统?我觉得不应该放在这个系统?

三、通过归纳法找特性

找特性首先是通过归纳法先找两个业务的共性,花呗支付和花呗分期都是互联网金融产品,都具备互联网产品属性和金融属性,花呗支付和花呗分期不一样的点就是分期的特性,主要体现在付费模式更多(有用户付息和用户免息),还款方式更多(3期、6期和12期),营销方式更多(全贴息和部分贴息)、以及服务角色更多(服务ISV)。再举一个例子,如果要精通JAVA要学习的内容会非常多,可能花很多时间学习也不一定能精通JAVA语言,投入产出比不高,但是如果想化繁为简就必须先找到JAVA的特性,针对特性进行深入学习,我觉得JAVA的两项特性技术是垃圾回收机制多线程框架,剩下的就和其他语言的特性差不多。大家会发现找特性和找共性是不是存在矛盾,所以在这个过程中需要做取舍,比如是否只满足共性需求不满足个性化需求,我觉得在某些场景下,取的是共性需求舍的是差异化需求,但是也可能在另外一些场景下取的是差异化的需求舍的是共性需求。关键是面对当下的业务,你判断什么当下或者未来最重要的事是什么,可能满足场景个性化需求虽然增加研发成本,但是能给业务带来技术壁垒,或者有没有一种方式能既满足共性需求又能满足部分个性化需求。

四、最后

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
Java架构设计涉及到了如何合理地组织和设计Java代码以满足系统需求,提高系统性能和可维护性。以下是一个具体的案例说明: 假设有一个电子商务平台,需要设计一个Java架构来支持其功能需求。在这个案例中,我们可以采用经典的三层架构来实现: 1. 表现层(Presentation Layer): 这一层主要负责与用户进行交互,并将用户的请求传递给中间层进行处理。在实现时,可以使用Java的Web框架(如Spring MVC)来处理用户请求,渲染页面并呈现数据。 2. 业务逻辑层(Business Logic Layer): 这一层主要负责处理业务逻辑,并调用数据访问层对数据进行读操作。在实现时,可以使用Java的业务逻辑组件(如Spring的Service组件)来实现各种业务逻辑,例如处理用户注册、购买商品等。 3. 数据访问层(Data Access Layer): 这一层主要负责与数据库进行交互,对数据进行持久化存储和访问。在实现时,可以使用Java的持久化框架(如Hibernate或MyBatis)来实现与数据库的交互,并进行数据的增删改查操作。 此外,为了提高系统的可扩展性和可维护性,我们还可以采用以下的设计模式和技术: 1. 设计模式: 例如工厂模式、观察者模式等,可以用来解耦系统不同部分之间的依赖关系,提高代码的可维护性和可扩展性。 2. 缓存: 使用缓存技术(如Redis)来提高系统的性能和响应速度,减少对数据库的直接访问。 3. 异步处理: 使用消息队列(如RabbitMQ)来实现任务的异步处理,提高系统的并发能力和吞吐量。 综上所述,这个案例说明了一个Java架构设计的实例,该架构通过三层架构来实现系统的功能需求,同时采用了一些设计模式和技术来提高系统性能、可扩展性和可维护性。这样的架构设计能够有效地满足电子商务平台的需求,并能够应对未来的扩展和变化。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值