Corda底层的交互过程

背景

从Corda中学到很多浅层的知识，比如整个架构体系，使用到的技术点（Fiber,Shiro,Netty,Hibernate,HikariCP,Artimis,Proton-j）和区块链概念（共识，智能合约，密码知识）

---

交互过程

大致说明：

1. Corda中一个节点既是服务端又是客户端。Netty, Artemis, Proton-j。过程就是Netty本身就是既是服务端又作为客户端，主题订阅模式就是Artemis并保证数据的可靠性。Proton-j内部通信连接引擎，并且对数据进行编码。（现在对通信数据编码常用开源工具是ProtoBuf）。

2. Netty中的是把channle注册到事件循环对象上，事件循环永远是一个单线程，在这个单线程上可以注册N个channel,可以理解这个channel对象为客户端的一个请求到来而创建的一个线程，每个channel都有与之对应的唯一ChannelPipeline，这个pipeline中有ChannelHandlerContext,这个ctx中持有Handler引用。这就是Netty的大致执行模式。但是Corda使用了Proton-j技术，把pipeline中的事件执行进行了转移，转移到了ConnectionStateMachine这个类中。所有事件的执行跟Netty的channel一样，都是单线程的，这里也是单线程的，因为Proton-j就是单线程进行执行的。

3. Corda自定义的EventProcessor事件处理器，是怎么关联上Proton-j的？它是通过继承proton-j的BaseHandler。

4. Corda自己写了一个事件处理器，把任务集中到一起，并且交付给jdk中的executor线程组去执行，这样就不会阻塞Netty的I/O操作了。这也是使用Netty的一个技巧之一。并且，这个handler也不是作者自己去实现的，而是它在githup找了是一个开源组件Proton-j，这个开源工具也是apache出品。于是在这个事件处理器中拿到所有的handler,然后一一执行。就相当于jdk的executor线程组中执行任务，这个任务跟Netty没有任何关系，是Proton-j完成代理执行。

5. 源码代码过程：
   a) AMQPServer中写好Netty的模式代码，利用它的Nio Socket模式（Reactor反应器模式），boosGroup和workerGroup。

   b) 自定义了一个ServerChannelInitializer继承ChannelInitializer，然后重写了initChannel方法，目的就是添加我们开发者自定义好的handler。

   c) 自定义了两个Handler：（1）SshHandler，（2）AMQPChannelHandler

   d） 模式做法，还是把AMQPChannelHandler和SshHandler添加到ChannelPipeline中。

   e) 这个AMQPChannelHandler持有EventProcessor。

   f) 当Netty的代码执行到这个AMQPChannelHandler时候，这个AMQPChannelHandler其实本质上是交给了EventProcessor去处理，这也是一个标准做法。并且这个任务是交给了jdk的executor这个线程组来执行这个任务。

   g) EventProcessor持有了一个list of handler(我们业务逻辑需要执行的)，这个任务的执行是交给了Proton-j去执行的。是异步执行。

   h) EventProcessor持有了一个ConnectionStateMachine实例，并把后续所有操作交给了ConnectionStateMachine实例去执行，这个实例其实是调用了Netty的Channel实例，然后响应给客户端的。

   i) 因为Netty设计了一个AttributeKey，Attribute, AttributeMap这个三个类，保证各个handler交替的时候，可以获取到相应的数据。并使用Channle.writeAndFlush方法给客户端响应，如果可能的话，使用ctx.writeAndFlush性能会更好，但是并不能保证我们需要Netty执行的每个handler都需要执行。

   j) 其实，在交给Proton-j执行的时候，就相应地把数据传输过去了。因为ConnectionStateMachine继承了Proton-j的BaseHandler()。重写了其中的方法，所以当Proton-j执行属于它的handler的时候，就会执行相应重写的方法。

   k) 而最后也就是由ConnectionStateMachine的实例，调用Netty的Channel.writeAndFlush操作。

   结论：Netty服务端使用Artemis的ip和port。通过jdk自己维护的executor线程组，执行我们的业务任务。任务是被Proton-j执行的，proton-j获得连接并带着用户名和密码，这个用户名和密码就是Artemis的用户名和密码，然后传输数据。最后由ConnectionStateMachine的实例调用了channel.writeAndFlush操作给客户端响应，完成整个逻辑执行。

---

问题

问题：理解为什么作者会使用AMQP作为类名的一部分？它与Artemis和Netty是怎样的关系？

答案：
a) 因为AMQP有一个地址和端口，这个地址和端口就给到了Netty进行绑定，然后收发数据。（AMQP是统一消息服务的应用层标准协议）

b) 收发数据的结果，是我们的Artemis接收到和主动发送的。

c) 而这些socket过程就是Netty替代的。Netty的I/O操作也会执行属于它自己的一些默认的handler。

d) 然而，使用Netty的一个技巧就是，如果业务代码比较耗时的情况下，那么我们应该使用jdk提供的executor这个线程组，把我们指定好的业务逻辑，当成一个个线程任务交给executor去执行即可。这样做的目的，是因为Netty执行所有的channel任务的时候是一个单线程而且是阻塞的，如果它在等待一个耗时的业务逻辑，那么这个性能就会非常差。由此，我们需要自己定义一个线程组去执行我们的业务逻辑代码。但是，Corda很聪明，它也不是直接使用jdk中的executor，然后new runnable的方式，而是使用其他的开源组件Proton-j的工具帮忙执行开发者自己定义好的handler。
e) 但是，并不是说，所有的handler都交给了Proton-j，而是把开发者自己定义好的业务逻辑代码交给了proton-j，而Netty自己原生的handler还是它自己去调用并处理的。也就是说，这是使用Netty的一个标准做法，而且做法的原因:Netty执行所有的channel任务的时候是一个单线程而且是阻塞的。

---

小结

1. 通过画图的方式，梳理Corda底层的大致交互过程。

2. 只要熟悉Netty的工作过程和使用技巧就能明白Corda的对Netty的使用。但是值得学习就是，Corda不是自己定义线程组并使用new Runnable的方式，而是使用其他开源组件Proton-j的来帮忙执行业务逻辑。

3. Corda打开了我的技术视野。Corda使用到的技术。还有常用开源技术，连接池(Hikari),持久层（Hibernate）,权限（Shiro）等等。

4. Corda里有很多区块链概念。比如网络（network），账单(ledger)，状态（States, 现实生活中的事物，或者理解为面向对象编程中的对象），交易（Transactions, 可以是任意有效的数据，有意义的数据，并非一定是数字货币的交易的那种概念），共识(Consensus)，智能合约(Contracts， Corda中就是可以自定义一个判断逻辑，这个逻辑执行结果只有两种可能要么是true,要么是false,其他区块链执行智能合约其实是业务逻辑，既然是业务逻辑，就可以执行任何有意义的代码了)，公证人（Notaries，可以有很多个，就是这些让交易数据达成共识），Oracles（先知，就好比一个系统如何与外界变化的状态保持一致，就是通过先知这个服务把外界的变化的事物录入系统），时间窗口（定义一个交易的在某个时间点之前或者之后有效或者某个时间段有效），Nodes（无数的节点，相互之间可以通信，通信的目的就是获取交易数据或者发送交易数据并且签名交易数据）。

5. Corda其实是利用区块链中的概念搭建了一个项目，这个项目其实就是解决传统银行清洁算的低效率。他认为传统清结算，银行之间的数据不同步，交互麻烦。于是，造了一个联盟链，很多的银行作为联盟链的一部分，一个用户发生交易，交易数据根据业务关系直接推送到相互关联的几家银行（联盟链中的节点 ），形成一个大的同步的有效的分布式账本。Corda这个项目非常稳定项目跑了一年也没有出现什么问题。

6. Corda项目有很多子项目，核心就三个（node,node-api,core）。node依赖node-api,而node-api项目依赖core。