![](https://img-blog.csdnimg.cn/20201014180756925.png?x-oss-process=image/resize,m_fixed,h_64,w_64)
架构实战案例
文章平均质量分 91
架构实战案例
_Rye_
左手代码右手诗
一行代码一行诗
展开
-
20 | 从务实的角度,架构设计的重点知识和学习路径
今天,汇总了常见的技术架构设计原则,它们都是实践的总结,在做架构设计时,可以参考这些原则,在项目中采取相应的手段来实现架构目标。值得注意的是,在做具体的架构设计时,需要对设计进行反复迭代,才能最终得到一个高性价比的方案。针对架构师的成长,也提供了相应的知识结构和可行的进阶之路,希望能够一步步成长,最终实现自己的理想。读万卷书,行万里路。架构师的成长尤其如此,架构没有速成之路,我们先要“读万卷书”,学习各种架构需要的技能,然后“行万里路”,通过大量的实践把架构知识变成架构能力。原创 2024-01-16 16:11:59 · 837 阅读 · 0 评论 -
19 | 综合案例:电商平台技术架构是如何演变的?
今天,基于一个简化的电商系统模型,分享了电商平台的技术架构发展过程,我们是如何通过一步步的架构升级,解决系统各个阶段出现的高可用、高性能和可伸缩问题的,相信现在对技术架构如何应对各种系统性挑战,有了更深入的认识。值得注意的是,系统的技术架构变化不一定要完全遵循这个过程,不同的业务、不同的发展阶段,对系统的要求都是不一样的,这里我给出的只是典型的问题和解决手段,希望在工作中,能够具体情况具体分析,灵活地运用这些手段。原创 2024-01-16 15:27:38 · 1042 阅读 · 0 评论 -
18 | 可伸缩架构案例:数据太多,如何无限扩展你的数据库?
1 号店在完成订单水平分库的同时,也实现了去 Oracle,设备从小型机换成了 X86 服务器,我们通过水平分库和去 Oracle,不但支持了订单量的未来增长,并且总体成本也大幅下降。不过由于去 Oracle 和订单分库一起实施,带来了双重的性能影响,我们花了很大精力做性能测试。为了模拟真实的线上场景,我们通过TCPCopy,把线上实际的查询流量引到测试环境,先后经过 13 轮的性能测试,最终 6 个 MySQL 库相对一个 Oracle,在当时的数据量下,SQL 执行时间基本持平。这样,我们。原创 2024-01-16 14:33:23 · 1143 阅读 · 0 评论 -
17 | 高性能架构案例:如何设计一个秒杀系统?
今天,针对 1 号店的大促业务挑战,分享了一个秒杀系统的具体设计,对照在上一讲中介绍的高性能应对策略,秒杀系统主要使用了异步化处理的方式,这也符合实际的业务场景。通过今天的分享,相信对如何保障系统的高性能有了更深入的体会,如果你也有类似的瞬时高并发的场景,也可以在实践中参考这里的做法。原创 2024-01-16 11:29:47 · 1122 阅读 · 0 评论 -
16 | 高性能和可伸缩架构:业务增长,能不能加台机器就搞定?
在课程的开始,给出了一些基础的性能指标,在具体的业务场景中,就可以参考这些指标,来评估当前系统的性能。另外,还分别针对系统的高性能和可伸缩目标,介绍了它们的实现策略和设计原则,在工作中,可以根据具体的业务,由易到难,采取合适的手段来实现这些目标。在实践中呢,实现高可用和可伸缩的手段也是多种多样的,接下来的课程中,还会通过实际的案例,来具体说明实现这些目标的有效手段,帮助更好地落地。原创 2024-01-16 09:18:18 · 852 阅读 · 0 评论 -
15 | 高可用架构案例(三):如何打造一体化的监控系统?
今天,分享了一体化监控系统具体的设计细节,相信已经非常清楚了它的内部实现机制,如果有需要,也可以在实践中尝试落地类似的监控系统。这里,讲得比较细,不仅仅是为了理解这个监控系统是怎么设计的,而是想分享做架构设计时,我们要做全面深入的考虑,要简化开发的对接工作,要简化用户的使用,这样的架构设计才能顺利落地,实现预期的价值。比如在这里,我们为 Web 应用提供了 SDK,这降低了开发者的接入成本;我们通过页面的动态布局设计,避免了前端开发工作的定制化;原创 2024-01-15 18:07:46 · 850 阅读 · 0 评论 -
14 | 高可用架构案例(二):如何第一时间知道系统哪里有问题?
今天,介绍了一下监控的分类,现在应该对监控有了比较深入的了解,知道一个完整的监控体系都包含了哪些内容。此外,也结合线上事故处理的例子,说明了碎片化的监控带来的一些问题,并给出了整体化的解决思路以及具体的落地方案。在实践中,这套监控系统也确实发挥了巨大的价值,让我们可以高效地应对线上事故,提升系统的可用性,希望能够深入地领悟和掌握。在下一讲中,还会介绍这个方案的实现细节。原创 2024-01-15 16:55:56 · 905 阅读 · 0 评论 -
13 | 高可用架构案例(一):如何实现O2O平台日订单500万?
先说下项目的背景。这是一个小程序点餐平台,用户在小程序上点餐并支付完成后,订单会先落到订单库,然后进一步推送到门店的收银系统;收银系统接单后,推送给后厨系统进行生产;同时返回小程序取餐码,用户可以凭取餐码去门店取餐或收取外卖。这个项目服务于一家大型的餐饮公司,公司在全国有大量的门店,他们准备搞一个长期的大型线上促销活动,促销的力度很大:用户可以在小程序上先领取优惠券,然后凭券再支付 1 元,就可以购买价值数十元的套餐。结合以往的经验,以及这次的促销力度,我们预计在高峰时,前端小程序请求将会达到。原创 2024-01-15 16:19:07 · 899 阅读 · 0 评论 -
12 | 高可用架构:如何让你的系统不掉链子?
今天,介绍了保障系统高可用都有哪些策略和设计原则,相信现在对高可用的整体处理思路有了清楚的认识。另外,还针对典型的系统处理过程,介绍了各个环节都有哪些具体的高可用手段,希望可以在工作中,结合系统的实际情况去落地它们。最后,留一道思考题:处理事故有三板斧的说法,你知道它们都是什么吗?你是怎么评价它们的呢?原创 2024-01-15 15:47:24 · 882 阅读 · 0 评论 -
11 | 技术架构:作为开发,你真的了解系统吗?
系统比我们想象的要复杂得多,这里,分享了系统的物理模型,相信不再局限于我们自己写的代码,而是对系统的整体结构有了更清晰的认识。还记得吗?在前面介绍业务架构时,分享的是系统 = 模块 + 关系,而在这里介绍技术架构时,分享的是系统的物理模型。因为业务架构解决的是系统功能性问题,我们更多的是从人出发,去更好地理解系统;而技术架构解决的是系统非功能性问题,我们在识别出业务上的性能、可用性等挑战后,更多的是从软硬件节点的处理能力出发,通过合理的技术选型和搭配,最终实现系统的高可用、高性能和可伸缩等目标。原创 2024-01-15 14:38:40 · 853 阅读 · 0 评论 -
10 | 可复用架构案例(三):中台是如何炼成的?
今天,从一个企业的订单业务变化出发,介绍了为什么要落地一个统一的订单服务,以及如何落地,并通过打造一系列类似的共享服务,逐步升级系统到中台架构。相信通过这个实际案例,进一步理解了如何通过共享服务和中台,实现业务能力的复用,并能根据公司的业务发展阶段,选择合适的时机、合适的架构,以接地气的方式对系统进行逐步改造。原创 2024-01-15 09:12:05 · 1055 阅读 · 0 评论 -
09 | 可复用架构案例(二):如何对现有系统做微服务改造?
基于现有系统进行改造和全新的服务设计是有所不同的,我们不能追求理想化和一步到位,而是要考虑到系统的平滑过渡,先实现微服务的顺利落地,后续再考虑各种优化。通过 1 号店库存微服务改造的例子,提供了一种可行的微服务落地套路,可以顺利地完成老系统的架构升级。原创 2024-01-12 19:56:20 · 1063 阅读 · 2 评论 -
08 | 可复用架构案例(一):如何设计一个基础服务?
说完了订单的状态管理,接下来,我们从调用方怎么使用服务的角度,来看下订单服务外部接口是如何设计的。外部系统和服务的交互有两种方式,包括同步的服务接口调用和异步的消息通知。首先是同步的服务接口调用。为了方便外部调用方,我们在服务接口命名时,一定要规范和统一,接口名字要能够望文生义,方便调用者快速找到所需要的接口。并且,我们还要提供接口具体的请求和响应样例帮助说明。具体的接口设计规范,我就不具体展开了,每个公司都要有明确的规范要求,这里我就说下常见的查询接口是如何设计的。原创 2024-01-12 18:56:49 · 1001 阅读 · 0 评论 -
07 | 可复用架构:如何实现高层次的复用?
既然是基础服务,它们就处于调用链的底层,服务之间不会有任何的调用关系,也就是说基础服务相互之间是正交的。比如说会员服务和商品服务,它们代表不同维度的基础业务域,彼此之间不会有调用关系。正交还有另外一种情况:服务之间有数据的依赖关系,但没有接口的调用关系。比如说,订单明细里包含商品 ID 信息,但订单服务内部不会调用商品服务来获取商品详情。如果页面需要展示订单的商品详情,针对这个具体的业务场景,我们可以在上层的聚合服务里,通过聚合订单服务和商品服务来实现。原创 2024-01-12 18:24:09 · 782 阅读 · 0 评论 -
06 | 可扩展架构案例(三):你真的需要一个中台吗?
中台是从企业的业务战略高度,来考虑企业 IT 系统的建设,它的目标是实现企业整体业务能力的复用。对于互联网企业来说,有大量微服务做基础,往中台转是改良,目的是更好地衔接前台和后台,实现业务的快速创新;对于传统企业来说,内部有大量的遗留系统,落地中台是革命,目的是盘活老系统,全面实现企业的数字化转型。互联网发展到现在,从最初的电商,到 O2O,再到现在的产业互联网,已经进入了深水区,很多传统企业都面临着数字化转型的挑战。原创 2024-01-12 17:40:33 · 984 阅读 · 0 评论 -
05 | 可扩展架构案例(二):App服务端架构是如何升级的?
今天,分享了 1 号店 App 服务端架构改造的实际例子。在这个例子中,架构经历了单体架构到分布式架构,再到 SOA 架构的变化过程,并且通过移动网关的方式,一定程度上实现了平台化。在这里,可以清晰地看到,公司每个阶段的业务,都有它不同的特点,我们选择的架构必须能够适配它,过度设计和设计不足,同样都是有害的。通过今天的分享,相信对各种架构的优缺点,以及业务上的适用性有了更进一步的了解。他山之石,可以攻玉。架构的策略和原则是通用的,希望能够通过实战不断去领会和运用。原创 2024-01-12 16:42:29 · 1039 阅读 · 0 评论 -
04 | 可扩展架构案例(一):电商平台架构是如何演变的?
今天,分享了电商平台架构的发展过程,从单体架构到分布式架构,再到 SOA 架构和微服务架构,每种架构都针对前一种架构的缺点做了改进,架构的扩展性也变得越来越好,可以满足更高的业务复杂性要求。但值得注意的是,每种架构都有两面性,既有优点,又有缺点,在实际系统中,这些架构也都是并存的。架构没有最好,只有最合适的。我们做架构设计时,一定要根据当前业务的特点,选择合适的架构。通过今天的分享,相信对架构的扩展性有了更深入的理解,也能够根据公司的业务现状,进行更合理的架构选型了。原创 2024-01-12 15:34:37 · 996 阅读 · 0 评论 -
03 | 可扩展架构:如何打造一个善变的柔性系统?
首先,我们对系统进行建模,系统 = 模块 + 关系,这样会简化对系统的认识。基于这个模型,我们对模块划分和关系定义提出具体的要求,可以在实际设计时参考这些要求。另外,我们深入地分析了扩展性的本质。系统的扩展能力来自于内部模块体系的有序,这样才能低成本地应对业务变化,认识到了这一点,有助于从根本上理解和重视架构的扩展性设计。然后,提供了一个出行平台的例子,来帮助理解,如何通过模块拆分和整合的手段,具体地设计一个可扩展的架构,希望能在工作中灵活运用。最后,留一道思考题。原创 2024-01-12 14:51:42 · 923 阅读 · 0 评论 -
02 | 业务架构:作为开发,你真的了解业务吗?
今天,了解了产品经理和业务架构师的不同职责,产品经理是站在用户的角度进行需求分析,而业务架构师是站在开发者的角度定义系统内部结构。通过今天的讲解,应该对业务架构也有了更清楚的认识。除了满足当前的业务需求外,业务架构师还需要面向未来,实现业务的可扩展和高复用两大目标,我也大致介绍了架构师实现这些目标的思路。在接下来的文章里,还会针对这两大目标,结合实际案例,具体讲解如何实现它们,更加深入地理解业务架构设计,并可以在工作中学会去运用这些手段。最后,留一道思考题。原创 2024-01-12 10:21:42 · 700 阅读 · 0 评论 -
01 | 架构的本质:如何打造一个有序的系统?
从上面的内容,我们不难看出,一个好的架构必须满足两方面挑战:业务复杂性和技术复杂性。一个优秀的架构师,应具备很强的综合能力,要内外兼修,“下得厨房,上得厅堂”,下面来通过典型的架构方式,来介绍一名优秀架构师应该具备的能力:一个驾校教练,必定开车技术好;一个游泳教练,必定游泳水平好,因为这些都是实践性很强的工作。架构师也是一样,TA 必定是一个出色的程序员,写的一手好代码。在此基础上,架构师要有技术的广度(多领域知识)和深度(技术前瞻)。原创 2024-01-12 09:10:59 · 886 阅读 · 0 评论 -
开篇词 | 想吃透架构?得看看真实、接地气的架构案例
那么在最后,我想说的是,架构对我们的工作是如此的重要,如果想深入学习架构,除了有好的学习方法,一定还要多思考,多交流,多实践。书上学来终觉浅,梅花香自苦寒来。好的指导方法加上你自身的努力实践,相信架构之路会越走越顺,越走越快。希望这个专栏,能够帮你开启架构师的进阶之路,让我们在架构之路上一起成长吧。原创 2024-01-12 09:07:12 · 942 阅读 · 0 评论