Dubbo作者聊 设计原则

以下内容均来自 梁飞 的个人博客 http://javatar.iteye.com/blog/1056664

• 魔鬼在细节
• 一些设计上的基本常识
• 谈谈扩充式扩展与增量式扩展
• 配置设计
• 设计实现的健壮性
• 防痴呆设计
• 扩展点重构

---

魔鬼在细节中

转于自己在公司的Blog：
http://pt.alibaba-inc.com/wp/experience_1301/code-detail.html

最近一直担心Dubbo分布式服务框架后续如果维护人员增多或变更，会出现质量的下降，
我在想，有没有什么是需要大家共同遵守的，
根据平时写代码时的一习惯，总结了一下在写代码过程中，尤其是框架代码，要时刻牢记的细节，
可能下面要讲的这些，大家都会觉得很简单，很基础，但要做到时刻牢记，
在每一行代码中都考虑这些因素，是需要很大耐心的，
大家经常说，魔鬼在细节中，确实如此。

1. 防止空指针和下标越界
这是我最不喜欢看到的异常，尤其在核心框架中，我更愿看到信息详细的参数不合法异常，
这也是一个健状的程序开发人员，在写每一行代码都应在潜意识中防止的异常，
基本上要能确保一次写完的代码，在不测试的情况，都不会出现这两个异常才算合格。

2. 保证线程安全性和可见性
对于框架的开发人员，对线程安全性和可见性的深入理解是最基本的要求，
需要开发人员，在写每一行代码时都应在潜意识中确保其正确性，
因为这种代码，在小并发下做功能测试时，会显得很正常，
但在高并发下就会出现莫明其妙的问题，而且场景很难重现，极难排查。

3. 尽早失败和前置断言
尽早失败也应该成为潜意识，在有传入参数和状态变化时，均在入口处全部断言，
一个不合法的值和状态，在第一时间就应报错，而不是等到要用时才报错，
因为等到要用时，可能前面已经修改其它相关状态，而在程序中很少有人去处理回滚逻辑，
这样报错后，其实内部状态可能已经混乱，极易在一个隐蔽分支上引发程序不可恢复。

4. 分离可靠操作和不可靠操作
这里的可靠是狭义的指是否会抛出异常或引起状态不一致，
比如，写入一个线程安全的Map，可以认为是可靠的，
而写入数据库等，可以认为是不可靠的，
开发人员必须在写每一行代码时，都注意它的可靠性与否，
在代码中尽量划分开，并对失败做异常处理，
并为容错，自我保护，自动恢复或切换等补偿逻辑提供清晰的切入点，
保证后续增加的代码不至于放错位置，而导致原先的容错处理陷入混乱。

5. 异常防御，但不忽略异常
这里讲的异常防御，指的是对非必须途径上的代码进行最大限度的容忍，
包括程序上的BUG，比如：获取程序的版本号，会通过扫描Manifest和jar包名称抓取版本号，
这个逻辑是辅助性的，但代码却不少，初步测试也没啥问题，
但应该在整个getVersion()中加上一个全函数的try-catch打印错误日志，并返回基本版本，
因为getVersion()可能存在未知特定场景异常，或被其他的开发人员误修改逻辑(但一般人员不会去掉try-catch)，
而如果它抛出异常会导致主流程异常，这是我们不希望看到的，
但这里要控制个度，不要随意try-catch，更不要无声无息的吃掉异常。

6. 缩小可变域和尽量final
如果一个类可以成为不变类(Immutable Class)，就优先将它设计成不变类，
不变类有天然的并发共享优势，减少同步或复制，而且可以有效帮忙分析线程安全的范围，
就算是可变类，对于从构造函数传入的引用，在类中持有时，最好将字段final，以免被中途误修改引用，
不要以为这个字段是私有的，这个类的代码都是我自己写的，不会出现对这个字段的重新赋值，
要考虑的一个因素是，这个代码可能被其他人修改，他不知道你的这个弱约定，final就是一个不变契约。

7. 降低修改时的误解性，不埋雷
前面不停的提到代码被其他人修改，这也开发人员要随时紧记的，
这个其他人包括未来的自己，你要总想着这个代码可能会有人去改它，
我应该给修改的人一点什么提示，让他知道我现在的设计意图，
而不要在程序里面加潜规则，或埋一些容易忽视的雷，
比如：你用null表示不可用，size等于0表示黑名单，
这就是一个雷，下一个修改者，包括你自己，都不会记得有这样的约定，
可能后面为了改某个其它BUG，不小心改到了这里，直接引爆故障。
对于这个例子，一个原则就是永远不要区分null引用和empty值。

8. 提高代码的可测性
这里的可测性主要指Mock的容易程度，和测试的隔离性，
至于测试的自动性，可重复性，非偶然性，无序性，完备性(全覆盖)，轻量性(可快速执行)，
一般开发人员，加上JUnit等工具的辅助基本都能做到，也能理解它的好处，只是工作量问题，
这里要特别强调的是测试用例的单一性(只测目标类本身)和隔离性(不传染失败)，
现在的测试代码，过于强调完备性，大量重复交叉测试，
看起来没啥坏处，但测试代码越多，维护代价越高，
经常出现的问题是，修改一行代码或加一个判断条件，引起100多个测试用例不通过，
时间一紧，谁有这个闲功夫去改这么多形态各异的测试用例？
久而久之，这个测试代码就已经不能真实反应代码现在的状况，很多时候会被迫绕过，
最好的情况是，修改一行代码，有且只有一行测试代码不通过，
如果修改了代码而测试用例还能通过，那也不行，表示测试没有覆盖到，
另外，可Mock性是隔离的基础，把间接依赖的逻辑屏蔽掉，
可Mock性的一个最大的杀手就是静态方法，尽量少用。

---

一些设计上的基本常识

转于自己在公司的Blog：
http://pt.alibaba-inc.com/wp/experience_886/software_design_general_knowledge.html

最近给团队新人讲了一些设计上的常识，可能会对其它的新人也有些帮助，
把暂时想到的几条，先记在这里。

1. API与SPI分离

框架或组件通常有两类客户，一个是使用者，一个是扩展者，
API(Application Programming Interface)是给使用者用的，
而SPI(Service Provide Interface)是给扩展者用的，
在设计时，尽量把它们隔离开，而不要混在一起，
也就是说，使用者是看不到扩展者写的实现的，
比如：一个Web框架，它有一个API接口叫Action，
里面有个execute()方法，是给使用者用来写业务逻辑的，
然后，Web框架有一个SPI接口给扩展者控制输出方式，
比如用velocity模板输出还是用json输出等，
如果这个Web框架使用一个都继承Action的VelocityAction和一个JsonAction做为扩展方式，
要用velocity模板输出的就继承VelocityAction，要用json输出的就继承JsonAction，
这就是API和SPI没有分离的反面例子，SPI接口混在了API接口中，
合理的方式是，有一个单独的Renderer接口，有VelocityRenderer和JsonRenderer实现，
Web框架将Action的输出转交给Renderer接口做渲染输出。

image.png

image.png

2. 服务域/实体域/会话域分离

任何框架或组件，总会有核心领域模型，比如：
Spring的Bean，Struts的Action，Dubbo的Service，Napoli的Queue等等
这个核心领域模型及其组成部分称为实体域，它代表着我们要操作的目标本身，
实体域通常是线程安全的，不管是通过不变类，同步状态，或复制的方式，
服务域也就是行为域，它是组件的功能集，同时也负责实体域和会话域的生命周期管理，
比如Spring的ApplicationContext，Dubbo的ServiceManager等，
服务域的对象通常会比较重，而且是线程安全的，并以单一实例服务于所有调用，
什么是会话？就是一次交互过程，
会话中重要的概念是上下文，什么是上下文？
比如我们说：“老地方见”，这里的“老地方”就是上下文信息，
为什么说“老地方”对方会知道，因为我们前面定义了“老地方”的具体内容，
所以说，上下文通常持有交互过程中的状态变量等，
会话对象通常较轻，每次请求都重新创建实例，请求结束后销毁。
简而言之：
把元信息交由实体域持有，
把一次请求中的临时状态由会话域持有，
由服务域贯穿整个过程。

image.png

image.png

3. 在重要的过程上设置拦截接口

如果你要写个远程调用框架，那远程调用的过程应该有一个统一的拦截接口，
如果你要写一个ORM框架，那至少SQL的执行过程，Mapping过程要有拦截接口，
如果你要写一个Web框架，那请求的执行过程应该要有拦截接口，
等等，没有哪个公用的框架可以Cover住所有需求，允许外置行为，是框架的基本扩展方式，
这样，如果有人想在远程调用前，验证下令牌，验证下黑白名单，统计下日志，
如果有人想在SQL执行前加下分页包装，做下数据权限控制，统计下SQL执行时间，
如果有人想在请求执行前检查下角色，包装下输入输出流，统计下请求量，
等等，就可以自行完成，而不用侵入框架内部，
拦截接口，通常是把过程本身用一个对象封装起来，传给拦截器链，
比如：远程调用主过程为invoke()，那拦截器接口通常为invoke(Invocation)，
Invocation对象封装了本来要执行过程的上下文，并且Invocation里有一个invoke()方法，
由拦截器决定什么时候执行，同时，Invocation也代表拦截器行为本身，
这样上一拦截器的Invocation其实是包装的下一拦截器的过程，
直到最后一个拦截器的Invocation是包装的最终的invoke()过程，
同理，SQL主过程为execute()，那拦截器接口通常为execute(Execution)，原理一样，
当然，实现方式可以任意，上面只是举例。