HBASE-Procedure架构

Posted 2023-05-01

参考技术A Hbase Procedure是HBASE服务端负责事物处理的一个架构，写的非常棒。。。可以扒下来改一改自己用的那种。。。

实现事物，需要处理的问题很多，主要的三个如下

对于事物的异常处理，要实现回滚操作。

对于未知状态处理，需要实现幂等与重试，当然实现分布式事物还有很多别的方面，这里省略。

HBASE的Procedure就是依据以上背景实现。

Procedure代表上述的流程部分，多个流程的划分为如果要执行下一个流程，那么需要将这两个流程之间的状态存储下来,也是幂等执行的最小单位。
最主要的三个方法为

Procedure之间是有派生关系的，即一个Procedure会派生出一个子Procedure，父Procedure和子Procedure共同组成一个事物，最顶层的流程为Root Procedure

对于资源的锁定：

执行Procedure的线程池。

保存事物的执行过程，用来在事物出错的时候，依次回滚事务，是一个栈结构。

用来在执行Procedure前存储Procedure的信息，用以在程序死亡重启时恢复执行事物。

用于组织执行Procedure的优先级

对Procedure的执行线程逻辑实现

架构之:软件架构漫谈

架构之:软件架构漫谈

目录

• 简介
• 什么是架构
• 架构的关键设计原则
• 架构的描述
  • UML
  • 架构视图
  • ADL
• 总结

简介

每一个程序员心中都有个架构师的梦想，架构是如此的重要，以至于每个程序员都在谈架构，仿佛没有架构的软件是没有灵魂的，不想做架构师的程序员不是一个好的码农一样。

那么架构到底是什么呢？架构是怎么得到的呢？今天本文将会从自身的经验来阐述一下对架构的看法。

什么是架构

在软件发展的初期是没有架构而言的。从最早的汇编语言到过程语言，他们处理的是一个个任务，为此编制了一个个的函数来执行对应的任务。这时候的软件编程语言还是过程语言，所以谈不上架构。

随着硬件技术的成熟，能够处理的任务越来越多，为了处理这么多的任务，编程语言也从面向过程转变为面向对象，从而更好的适应任务的发展。软件越来复杂，要处理的任务越来越多，最终导致了系统架构的产生。

架构是在复杂软件结构中产生的，它的任务就是让这些复杂软件中的任务能够互相协作从而来完成共同的任务。当然这是从软件的目标来说的。如果再考虑软件的实现和扩展性，那么好的架构需要让系统可读性和可扩展性更强，给未来留出一定的空间。如果从可靠性和可用性来讲，好的架构还需要保证系统高可用和容错性。

我们要注意的是，架构并不是空想而来的，它的基石在于编写的程序。所以架构需要跟程序紧密结合才能产生活力。

系统的架构主要描述的是系统的主要组件和这些组件之间的关系和他们如何进行交互。

架构的关键设计原则

为了最大程度的降低成本，满足功能需求，并最大程度的提高系统结构的可扩展性和可用性，我们需要考虑下面几个关键的设计原则：

1. 关注点分离原则

将系统的组件按照特定的功能进行划分，从而是组件的功能之间没有重复。从而保证高内聚力和低耦合度。这种方法避免了系统组件之间的相互依赖性，有助于简化系统。

2. 单一责任原则

系统的每个模块都应负一个特定的责任，这有助于用户清楚地了解系统。它还有助于组件与其他组件的集成。

3. 最少知识原理

任何组件或对象都不应该获取其他组件的内部细节。这种方法避免了相互依赖，并提高可维护性。

4. 最大限度地减少前期的大型设计

如果应用程序的需求不清楚，则最大程度地减少前期的大型设计。从小的原型出发，在探索中确认好需求。避免后期因为需求变动导致的巨大重构工作量。

5. 不要重复功能

“不重复功能”指的是不要重复组件的功能，一个逻辑的实现，只应该存在于一段代码中。如果有多处代码的拷贝，那么在逻辑发生变化的时候，功能的重复会使其难以实施更改，降低清晰度并引入潜在的不一致之处。

6. 重用功能时要优先考虑组合而不是继承

继承会在子类和父类之间建立依赖关系，因此会阻止子类的自由使用。相反，组合提供了很大的自由度并减少了继承层次结构。

7. 定义不同层之间的通信协议

要对部署方案和生产环境有完整的了解，从而制定出或者使用合适的通信协议。

8. 定义组件之间交互的数据格式

各种组件将通过数据格式相互交互。最好统一数据格式，从而使应用程序易于实现，扩展和维护。通过使用相同的数据格式，以便各个组件在相互通信时无需对数据进行编码/解码。它减少了处理开销。

9. 系统服务组件应该是抽象的

与安全性，通信或系统服务（例如日志记录，概要文件和配置）相关的代码应在单独的组件中抽象出来。请勿将此代码与业务逻辑混合使用，这样扩展设计和维护将会变得容易。

10. 设计异常和异常处理机制

预先定义异常，有助于组件以优雅的方式管理错误或意外情况。最好在整个系统中使用相同的异常处理机制。

11. 命名约定

命名约定应事先定义。它们提供了一个一致的模型，可以帮助用户轻松理解系统。团队成员更容易验证其他人编写的代码，因此会增加可维护性。

架构的描述

既然架构这么重要，我们可以使用什么样的手段才能够描述架构中的组件、组件之间的联系和他们的交互呢？业界也探讨了很多方法。这里我们也来介绍几种方法。

UML

UML大家应该都很熟悉了，它的全称是统一建模语言，它是一种图形语言。UML1.0规范是在1997年1月由对象管理组（OMG）提出的。它用作软件需求分析和设计文档的标准，这些文档是开发软件的基础。

UML是可视化的建模语言，里面包含很多组件，这些组件通过不同的方式关联，从而形成了完整的UML图。尽管通常使用UML对软件系统进行建模，但它并不局限于此范围。UML也被用于建模非软件系统，例如制造单元中的流程。

UML主要分成两大类别：结构图和行为图。

结构图表示系统的静态组件。 这些静态组件由类，接口，对象，组件和节点表示。结构图包含下面几个部分：

1. 类图： 表示面向对象系统中的各个类和他们间的关系。
2. 对象图：对象图表示的是运行时的对象和他们的关系。
3. 组件图：组件图描述的是系统中的所有组件、接口和他们的交互关系。
4. 复合结构：描述组件的内部结构，包括所有类，组件的接口等。
5. 包：包主要是包含类和其他的包。
6. 部署图：部署图是一组节点及其关系。 这些节点是部署组件的物理实体。

行为图表示的是系统中可能出现的动作，行为图可以包含下面几种：

1. 用例图：描述功能及其内部/外部控制器之间的关系。 这些控制器被称为参与者。
2. 活动图：描述系统中的控制流。 它由活动和链接组成。 该流可以是顺序的，并发的或分支的。
3. 状态图：表示系统的事件驱动状态更改。 它描述了类，接口等的状态变化。
4. 序列图：可视化系统中执行特定功能的顺序。
5. 组合活动图和序列图以提供系统和业务流程的控制流概述。

架构视图

视图是从一组相关关注点的角度对整个系统的表示。它用于从不同的利益相关者（例如最终用户，开发人员，项目经理和测试人员）的角度描述系统。这里给大家介绍一个叫做4 + 1的视图模式。

4 + 1视图模型是由Philippe Kruchten发明的。该模型基于对多个视图和并发视图的使用来描述软件密集型系统的体系结构。它是一个多视图模型，解决了系统的不同功能和关注点。它使软件设计文档标准化，并使所有利益相关者易于理解设计。

它包含了4个基本的视图，分别是：

1. 逻辑视图或概念视图-它描述了设计的对象模型。    
   2.  流程视图-描述了系统的活动，包括并发和同步。     
   3. 物理视图-它描述了软件到硬件的映射并反映了其分布式关系。   
   4.  开发视图-它描述了环境开发中软件的静态组织和结构。

最后的+1视图表示的是为最终用户或客户添加一个称为方案视图或用例视图的视图。它和其他的4个视图是一致的，所以被称为+1 视图。

ADL

架构描述语言ADL是一种语言，提供用于定义软件体系结构的语法和语义。它是一种注释规范，提供了用于对软件系统的概念体系结构进行建模的功能，这与系统的实现有所不同。

架构描述语言是一种形式化的规范语言，它描述诸如进程，线程，数据和子程序之类的软件功能，以及诸如处理器，设备，总线和内存之类的硬件组件。

总结

今天的架构漫谈就讲到这里，有不住之处还希望大家多多指正。后续会给大家介绍几种常见的架构模式。希望大家能够喜欢。

本文已收录于 http://www.flydean.com/06-software-architecture/

最通俗的解读，最深刻的干货，最简洁的教程，众多你不知道的小技巧等你来发现！

欢迎关注我的公众号:「程序那些事」,懂技术，更懂你！