编写自己的分布式框架—事物篇（一）

概述

从文章的标题可以知道，这系列的文章主要是讲：一个java框架是如何开发出来的。看到这里，可能已经有部分小伙伴不明觉厉了。
  但其实，开发一个框架并不是什么很神秘、很高大上的事情，就跟我们平时做业务类的项目差不多，这个差不多指的是开发形式上差不多。不一样的地方就在于思想上要做一个转变，我们要从使用别人提供的功能，转变为提供功能给别人使用。这看似很简单的一句话，但却非常关键，所以有必要再强调一次：“提供功能给别人使用”。有过框架开发经验的开发者都知道，在开发一个框架的过程中，都会不断的对自己说，“我这个功能是提供给别人用的，怎么才能让别人用起来简单一点，最好让别人少写代码”，“需要怎么提高性能和安全，让别人用起来安心一点”，“为了应对某些人有特殊的需求，所以必须要提高扩展性”。等等的这些话都是在我们开发一个框架的过程中，不断提醒自己的，而这些话，正是开发框架应该具备的思想，在这些思想指引下，我们才会想方设法的使用各种技术来实现目标。
  回到我们做业务项目上，更多的是要求快点把功能完成，为了达到这个要求，我们就会不断的提醒自己：“代码重复不要紧，后面有时间再重构”，“性能很差不要紧，后面有时间再优化”，但往往后面就不会重构和优化了，因为那时，项目可能已经很臃肿，看都不想去看了。这种情况，在开发框架项目上是绝对不能有的，所以说开发框架的话，一定要转变自己的思想。
  还有一部分的小伙伴看到这个标题后，可能会想，标题党又来了，什么写框架啊，到头来估计又是在讲概念，讲思想就完事了。首先，概念和思想是肯定要讲的，然后，我们才真正的从0开始去开发一个框架。但是，关键不是这个框架本身，而是做这个框架的过程，所以不要太在意接下来要做什么框架，解决什么问题。而是需要在意做框架的过程中，它的方法和思想，这样我们才能举一反三，触类旁通。

怎么理解“框架”

可能很多小伙伴从学习java的那一刻起，就跟着老师说，这框架那框架的，但是老师从来没有提过什么是框架，自己也没有思考过，框架是什么，就知道这个就是框架了，那个不是框架，对框架的概念理解很模糊，那现在，我们就来普及一些基础常识，比如插件、框架、中间件这些术语的来龙去脉。
  首先，框架的出现是我们对于“复用性”的要求越来越高，不想重复造轮子，从最初的单个函数的复用，到面向对象中类的复用，再到由多个类组成的lib包，提供类库的复用。复用软件的抽象层次越来越高，而框架就在这种背景下产生的。框架复用是抽象层次的又一提升，框架的复用不仅仅是功能的复用，更是设计的复用。
  我们在来看看框架的含义：框架是一个半成品的应用，它封装了某领域内处理流程的控制逻辑，由于软件开发各种领域问题众多，所以框架必须具有针对性，比如，有针对底层通讯领域的框架，有针对分布式应用领域的框架，有针对对象关系映射领域的框架等等。框架这个半成品应用像是一个骨架，然后我们在这个骨架上添加血和肉，就是我们具体的业务代码了，然后组成一个完整的应用。
  框架我们就了解到这里，接着我们来扩展一下，看看什么是插件，什么是中间件。插件其实就类似我们上面提到的“类库”了，由于复用性的要求，我们需要把一些重复使用的功能抽取出来，而这个功能的实现又需要多个类组成，那么把这多个类打成一个包，以工具的形式提供某种类型的功能给别使用，就是类库或者说插件了，它不能单独成为一个应用。比如：二维码生成工具、文件操作工具、报表生成工具等等。打个比喻，如果说框架是骨架，我们的业务功能是血和肉，那么插件或者说工具类库就像是：牙齿、头发和指甲之类的了，有它们最好，没有也不会死。最后来看看什么是“中间件”，不同于刚刚说的框架和插件，框架、插件和我们的业务代码共同组成一个应用，而中间件它本身就是一个独立运行，并且是完整的一个应用，不是半成品应用，这种类型的应用主要是对外提供某种领域的网络服务给其他应用使用，比如：数据库服务中间件，分布式缓存中间件，消息队列中间件，搜索引擎中间件等等。打个比喻的话，就是你的合伙人，你的队友之类的，你们每个独立的个体相互合作，共同完成某个目标。

具体目的

该铺垫的东西我们已经铺垫好了，接下来就要准备动手开发这个框架了。通过上面对框架的了解，我们知道，每个具体的框架都是在解决特点领域问题的，那这样的话，我们接下来要开发的这个框架是解决什么领域的问题呢？这个领域的选择也是不能随意的，首先，需要排除那些老旧的领域：比如ORM、MVC这些领域，因为这些领域制造不了多少话题。还要排除解决方案非常成熟的领域：比如底层通讯，分布式应用，这些领域因为发展的时间比较长，都比较成熟和完善了，也就没有多大的必要再拿来研究。那经过排除之后，我们就选择现在比较热门的话题，面试的时候也是经常问到的，并且现阶段，还没有一个非常成熟的解决方案，就是：“分布式事务”，我们用这个领域的问题作为载体，去开发一个分布式事务框架。但是，还是需要再强调一下，我们的目的是学习框架的开发过程，而不是这个具体的分布式事务框架。

注：阿里在18年年底开源了一个分布式事务框架：fescar。地址为：https://github.com/alibaba/fescar，虽然现阶段还不是很完善，但看阿里官方的规划，后面的版本是会越来越强大的，大家有时间可以上去学习一下。

在开发这个分布式事务框架的过程中，我们会学到很多技术，学习这些技术才是我们开发这个框架的目的，而这些技术又是在平时我们做业务类的项目很少有机会接触的，具体如下：

• 注解的使用
    我们这里所说的注解的使用，并不是指平时我们做业务功能时，贴一个注解就完事的那种用，而是去定义一个注解，然后给该注解赋予一个意义，也就是说，我贴了这个注解，能帮我完成什么功能。在我们做业务项目的过程中，是很少有机会让我们去定义注解的，而做框架就不一样了，我们上文提到的，做框架其中一个思想：易用性，如果你想让你的框架，在给别人用的时候，是很简单的，那就需要考虑使用注解了，被人不用怎么去写代码，只需要贴个注解，然后框架就帮他做完了事情。
• 并发的使用
    很多小伙伴经常反映，java下的并发包（concurrent）下的东西很少使用，我们如果是做业务类的项目，那确实是这样的，但是如果我们要做框架，那就不是了，因为性能和安全也是做框架的一个指导思想，每时每刻都需要思考，什么功能需要使用多线程来提高性能，什么功能又会不会因为并发，导致出现安全问题。在开发的时候就需要精心设计了，而不是说开发完了再优化，不然的话，我相信做出来的框架不会有人敢冒险使用的。
• SPI的使用
    SPI是Service Provider Interface的简写，这项技术也是平时我们做业务项目没机会接触的，我们知道，一个好的框架，肯定是一个扩展性很强的框架，这个在我们上文讲开发框架的指导思想时也提到了，也就是扩展性。接下来我们再慢慢揭开SPI的神秘面纱。
• 设计模式的使用
    最后需要提及的技术就是设计思想，这个可以说是一个框架的灵魂了，我们在讲框架概念的时候提到，框架就是对软件“复用性”的要求越来越高的产物，使用硬编码是肯定不能达到“复用性”的要求的，所以，各种设计模式就应运而生了。在开发框架的过程中，我们会接触一些业务项目没机会接触的设计模式，比如动态代理模式，工厂模式，策略模式，适配器模式。
    学习以上的这些技术才是我为什么要写这个专题文章的目的，我想每一个程序猿都有一个小目标，不是赚一个亿，而是做架构狮，当然，架构狮是会写业务代码的，因为任何开发语言的架构狮都是从一线开发成长起来的，但是只会写业务代码的程序猿是不可能做架构狮的，而掌握以上技术，就是成为架构狮的第一步。