框架设计原则
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
大纲
模块分包原则
框架扩展原则
模型划分原则
接口分离原则
组件协作原则
功能演进原则
R P C
R e m o 'n g
B u s i n e s s
refer
received
request connect bind
connect
bind
send
reply
invoke
invoke
encode merge write read
getProxy
getInvoker
export
refer
decode serialize
select list
register getExecutor noEfy
getRegistry
noEfy
list invoke invoke Provider Consumer Exporter
Interface
Proxy
Filter
Invoker Invoker
Filter Implement
Client
Server Transporter
LoadBalance
Protocol
NoEfyListener
Registry
Protocol
Registry
Exchange Service
SerializaEon Inherit Init Dubbo F ramework
Depend
DubboInvoker DubboProtocol DubboExporter
Interface Class ProxyFactory
Invoker
Proxy ReferenceConfig
ServiceConfig
Config Call Cluster Codec
ObjectOutput ObjectInput Exchanger Transport
Serialize Directory Cluster
ThreadPool
RegistryProtocol U s e r A P I
C o n t r i b u t o r S P I RegistryFactory RegistryDirectory
deserialize export
invoke
invoke
invoke export ChannelHandler
ExchangeHandler
Router
RouterFactory
Monitor Monitor MonitorFactory route MonitorFilter
ExchangeSerever ExchangeClient count refer
received getMonitor
Start get export
invoke
invoke
new
subscribe Dispatcher getRouter dispatch
DubboHandler merge getRouter
getRegistry
getMonitor
wrap connect connect bind
bind
模块分包原则 • 复用度
– 包中的类应该有同样的重用可能性,
– 紧密协作的类应该放在一个包。
– 对于变化因子,包中的类应全改或全不改,
– 变化应在包内终止,而不传播到其它包。
– 发布的粒度和复用度相同。
• 稳定度
– 被依赖的包应该总是比依赖者更稳定,
– 不要让一个稳定的包依赖于不稳定包。
– 单向依赖,无环依赖。
• 抽象度
– 越稳定的包应该越抽象,
– 稳定的包不抽象将导致扩展性极差,
– 抽象的包不稳定将导致其依赖包跟随变化。
稳定
不稳定
非常不稳定
抽象
具体 package
import c om.foo.*
• I = C e / (Ca + C e)
I: I nstability
Ca: Afferent C oupling (Used b y p ackges)
Ce: Efferent C oupling (Depend u pon p ackges)
• A = N a / N c
A: A bstractness
Na: N umber o f a bstract c lasses
Nc: N umber o f c lasses (Include a bstract
classes)
JDepend • D = a bs(1 -‐ I -‐ A) * s in(45)
D: D istance
I: I nstability
A: A bstractness
大纲
模块分包原则
框架扩展原则
模型划分原则
接口分离原则
组件协作原则
功能演进原则
平等对待第三方
• Dogfooding
– 框架自己的功能也要扩展点实现
– 甚至微核的加载方式也可以扩展
• Autowire
– 装配逻辑由扩展点之间互助完成
– 杜绝硬编码的桥接和中间代码
• Cascading
– 层叠扩展粒度,逐级细分
– 由大的扩展点加载小的扩展点
• Law o f D emeter
– 只与触手可及的扩展点交互,间接转发 – 保持行为单一,输入输出明确
Dogfooding Autowire