【杉枫】架构抽象化设计

业务研发，到了一定阶段需要对设计进行抽象化进行，抽象化两种方式一种是程序库，通过调用库形式实现代码重用，例如 dll、so、jar 包，另一种形式是通过服务形式，比如 Web 服务 soa 以及当下微服务形式对业务模块进行抽象化设计。

对于线上业务抽象化去实现，具体到实现方式上，在 Java 语言上存在两种方式，一种 jar 包形式，一种是服务方式。两种方式各有优劣，两种方式结合着用，用两种方式优势，能够将架构实现更合理获得更多形式上重用。

jar 包形式，将逻辑进行抽象实现，能够引入在业务服务中使用，使用 jar 包时要注意基于 Spring jar，如果多线程使用时，要注意类引用方式，再多线程中单独加载，然后在使用。

throwable 异常机制，整个异常指责链，异常继承体系要明确。避免异常捕获不到情况，导致程序异常。异常框架以及异常体系结构：

• 本文地址：【杉枫】架构抽象化设计
• 本文版权归作者和AIQ共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出

thread local 机制，thread local 本身是绑定在每个线程上的对象，使用时需要 thread local 本身是静态的，这样才能保证变量是全局的且唯一。使用样例类似如下：

架构设计最终落到实现上，需要对使用到语言层面比如线程池、synchronized 、countdownlatch 理解要深入，对于库层面 Spring 也是，类似整体加载机制要明确，不然整个实现会遇到各种问题，会因为点的卡壳而花费大量时间。

对于 synchronized 在作用于块的时候，要锁定唯一对象，对象唯一性很重要不然可能导致锁不住，锁住后的整个流程单线程模式，所以锁住模块要尽量小，尽量小之后才能获得更高性能。

在有就是版本，Spring 版本是 4 就要注意 spring-conifg.xml 中头部 head 版本，版本不一致可能会导致整个个别功能起作用，部分功能不起作用，最近遇到 4.0 Spring 配置文件 3.0 然后基于注解方式定时器不起作用。

架构设计本质上还是降低复杂度，实现业务需要，架构本身需要不断演进，不能期望一步到位，并且扩展性也是在一定范围内，而不是无限制可扩展性。架构取决于设计者对于业务理解深度，以及对于各种基础知识掌握以及熟练运用程度。

文章零散说了很多方面，其实说的就是一件事，架构设计到实现又一个巨大鸿沟以及一个漫长实现过程，需要对各个知识点以及库体系有相当了解，才能很好去实现，不然会导致事倍功半。