架构实战案例解析
王庆友
前1号店首席架构师
立即订阅
2075 人已学习
课程目录
已更新 17 讲 / 共 22 讲
0/4登录后，你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 想吃透架构？你得看看真实、接地气的架构案例
免费
概述篇 (1讲)
01 | 架构的本质：如何打造一个有序的系统？
业务架构篇 (9讲)
02 | 业务架构：作为开发，你真的了解业务吗？
03 | 可扩展架构：如何打造一个善变的柔性系统？
04 | 可扩展架构案例（一）：电商平台架构是如何演变的？
05 | 可扩展架构案例（二）：App服务端架构是如何升级的？
06 | 可扩展架构案例（三）：你真的需要一个中台吗？
07 | 可复用架构：如何实现高层次的复用？
08 | 可复用架构案例（一）：如何设计一个基础服务？
09 | 可复用架构案例（二）：如何对现有系统做微服务改造？
10 | 可复用架构案例（三）：中台是如何炼成的？
技术架构篇 (6讲)
11 | 技术架构：作为开发，你真的了解系统吗？
12 | 高可用架构：如何让你的系统不掉链子？
13 | 高可用架构案例（一）：如何实现O2O平台日订单500万？
14 | 高可用架构案例（二）：如何第一时间知道系统哪里有问题？
15 | 高可用架构案例（三）：如何打造一体化的监控系统？
16 | 高性能和可伸缩架构：业务增长，能不能加台机器就搞定？
架构实战案例解析
登录|注册
07 | 可复用架构：如何实现高层次的复用？
王庆友 2020-03-06
你好，我是王庆友。在前面几讲中，我们讨论了如何打造一个可扩展的架构，相信你对架构的可扩展有了一定的了解，而架构还有一个非常重要的目标，那就是可复用。所以从今天开始，我就来和你聊一聊，如何打造可复用的架构。
作为开发人员，你对复用这个概念一定不陌生。在开发过程中，我们把系统中通用的代码逻辑抽取出来，变成公共方法或公共类，然后在多个地方调用，这就是最简单的技术上的复用。
但一开始，我们不会过多地考虑复用，当一个新项目过来，我们会选择最直接的方式来实现，结果往往是欲速而不达，比如说：
好不容易搞定了一个项目，接着又有新的类似项目过来，我们又要从头再来；
项目的代码是定制的，项目结束后，系统维护的噩梦刚刚开始。
如果项目缺乏沉淀，每个项目都是全新的开始，出现这些情况，一点都不意外。而要想解决这个问题，我们一开始就要考虑系统的复用性。
复用，它可以让我们站在巨人的肩膀上，基于现有的成果，快速落地一个新系统。
那么，我们在做架构设计时，如何实现系统的高可复用呢？
今天，我就针对复用这个话题，首先和你介绍一下，复用具体都有哪些形式；然后，我会针对最有价值的业务复用，带你了解如何划分服务的边界，让你能够在工作中，设计一个可以高度复用的系统。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《架构实战案例解析》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(15)
Mandalorian 置顶老师请讲讲订单服务，
订单小票包含了价格，价格涉及到优惠信息。
价格信息来自商品服务，优惠信息来自促销服务。订单服务从数据上依赖商品服务、促销服务。
请问这个订单小票，是订单服务的功能呢？还是上层聚合服务的功能呢？
订单服务本身负责什么呢？作者回复: 这个比较复杂，大家不要陷入这个具体的业务里面。
具体讲，就是
1. 上层应用调用促销服务，把购物车的商品信息和用户信息传进去，返回的是最终订单金额，以及因为各个优惠减免的金额。这个是促销服务结合内部的促销规则记性计算
2. 然后上层应用调用订单服务，把订单的信息，以及优惠结果传进去，订单服务负责在数据里保存优惠结果。
所以是上层应用调各个基础服务，基础服务之间不会互相调。2020-03-12 1 2
孙同学https://www.processon.com/view/link/5e51378ce4b0c037b5f9d1e3 冗余一定程度的数据可以简化上层的业务聚合调用，不过在存储数据时也会增加相应的复杂度，这应该是个辨证关系，看常用业务流程而定吧。不知道理解的对不对2020-03-06 5
Middleware冗余一些数据，字段，我认为适当的场景是很有必要的。检索数据方便，查询效率也会提高2020-03-06 1
Din冗余其他服务的数据时比较常见的做法，这样可以减少和其他系统数据的交互，提高服务性能。不过数据一旦冗余，就会带来数据一致性的问题。2020-03-06 1
每天晒白牙冗余数据有时也是可以的，就像电商中有买家查数据的需求，也有卖家查数据的需求，在做分表时为了提升性能会做冗余2020-03-06 1
AngryApe王老师，请教一个问题：在架构设计的时候服务一般的分层的，基础服务层（业务实体），共享业务层，应用服务层，按这个结构的话是否允许应用服务层直接调用基础服务层？比如一个简单的查询优惠券详情，没有什么复杂的逻辑，这时候应用层是否应该直接调用基础服务层？作者回复: 可以跨层调，你这里的共享业务层是聚合业务层吧? 基础业务层提供的就是共享业务
2020-03-17
ROCKETsFORWARD空间换时间的做法。有时为了避免跨库join，需要保证查询效率时，可以本地冗余其他服务的数据。一般情况下冗余不常变化的数据。当冗余数据有变化的时候，可以开启定时任务在业务不繁忙的时候进行更新，保证最终一致性。2020-03-15
曌冗余存储其他服务的数据好处是查询效率高，单个服务就能满足业务需求，无序聚合查询其他服务，但是也要注意冗余的度，要综合考虑到数据一致性和性能来做决定。2020-03-08
dowannado20200307 高复用 代码 技术组件 业务实体 业务流程 业务 完整性 一致性 正交 基础服务边界划分原则等2020-03-07
小伟在持久化数据中还是尽量少冗余其他服务的数据，因为维护一致性的开销较大。
如果某些服务数据是热点且变化频率不高，则可使用外部缓存提升性能，如redis。
如果热点数据变化大且一致性要求强，还是每次去调服务接口吧。2020-03-07
卫江之所以冗余数据，说明该服务需要这些数据，但是又不想因为获取该冗余的数据而对其他的服务产生依赖而违背了我们的正交原则，但是就会有一致性问题，多个服务维护同一份数据的问题，如果这一块的冗余可以通过聚合层来避免，把相关的这一块的逻辑放在上层的聚合层来减少底层的冗余。2020-03-07
Alex我们在落地服务时，有时会冗余存储其它服务的数据。典型的空间换时间的做法。对于特定业务需求避免了服务间的联合查询，简化实现难度减少时间消耗。但要注意冗余数据带来的一致性问题。2020-03-07
tt冗余数据是为了业务实现的方便和效率吧，应该不能无条件的否决，但如果后续无法控制住这些数据的生长，可能会带来问题。
老师的课太赞了，篇篇精华，信息量大，又都重点明确。
我停下来的感觉，就是要紧紧的抓住服务是为业务服务的，业务是由数据和规则实现的。可扩展的下层是可复用，复用的前提是清晰的边界及正交分解的服务。
划分边界时，就是要紧紧的围绕数据和规则，做到不同服务间的数据交换最少化，规则上互相不调用。（又想到了设计模式中的单一职责原则和迪米特原则等）
然后通过上层的聚合服务去平台化、通用化这些底层基础服务，从而做到层次分明。2020-03-06
探索无止境冗余数据的作用，我认为是为了提高查询性能，老师的课非常清晰到位，如果再附上一些代码就完美了2020-03-06
Jeff.Smile要点总结:
业务上的复用比纯粹的技术复用有更高的价值，我们要尽量往这个方向上靠。
在实践中，落地基础服务是实现业务复用的有效方式，而基础服务边界的划分，它有科学的成分，但更多的是一种艺术。一般有:完整性、一致性、正交性。
思考题:
冗余数据可为了提升性能。2020-03-06
收起评论