软件架构常用设计

shaderdx

已于 2025-03-05 12:22:36 修改

阅读量9.5k

点赞数 7

CC 4.0 BY-SA版权

文章标签：系统架构数据库架构 linux c++

于 2023-03-25 20:24:22 首次发布

本文链接：https://blog.youkuaiyun.com/shaderdx/article/details/129769350

一、单体架构 (Monolithic Architecture)

描述：所有软件组件都运行在同一个进程或服务中，通常是传统的软件开发方式。
适用场景：小型应用或者简单的应用。

优点：简单易懂；部署方便；开发、测试流程简化。
缺点：可扩展性差；随着系统复杂度增加，维护难度升高；技术债务累积快。

实现原理：单体架构将所有功能集成到一个独立的应用程序中，通常由一个数据库支持。它可以是一组紧密耦合的代码模块，通常按功能分层。
例子：传统的电商网站，所有功能（产品展示、订单处理、支付、用户管理）都在同一个应用程序中实现。

二、分层架构 (Layered Architecture)

描述：软件被分为多个层次，如表示层、业务逻辑层、持久层等，每层只与相邻的层次通信。
适用场景：大多数企业应用。

优点：组织清晰，层次分明；促进关注点分离；提高了可维护性。
缺点：层与层之间紧密耦合，难以修改；性能损耗。

实现原理：分层架构将应用程序分为几个层次，每一层只与其上下直接相邻的层次通信。典型的分层包括表示层、业务逻辑层、持久层等。
例子：Web应用程序，其中前端作为表示层，后端服务作为业务逻辑层，数据库作为持久层。

1.四层架构：

分层架构（layered architecture）是最常见的软件架构，也是事实上的标准架构。如果你不知道要用什么架构，那就用它。

这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。

虽然没有明确约定，软件一定要分成多少层，但是四层的结构最常见。

（一）表现层（presentation）：

用户UI界面，负责视觉和用户互动

（二）业务层（business）：

实现业务逻辑

（三）持久层（persistence）：

提供数据，SQL 语句就放在这一层

（四）数据库（database）：

保存数据

有的软件在逻辑层和持久层之间，加了一个服务层（service），提供不同业务逻辑需要的一些通用接口。

2.也有三层架构的：

（一）UI（User Interface）层

职责是数据的展现和采集，数据采集的结果通常以Entity object提交给BL层处理。Service Interface侧层用于将业务或数据资源发布为服务（如WebServices）。

（二）BL（Business Logic）层

职责是按预定的业务逻辑处理UI层提交的请求。

（1）Business Function 子层负责基本业务功能的实现。

（2）Business Flow 子层负责将Business Function子层提供的多个基本业务功能组织成一个完整的业务流。（Transaction只能在Business Flow 子层开启。）

（三）ResourceAccess层

职责是提供全面的资源访问功能支持，并向上层屏蔽资源的来源。

（1）BEM（Business Entity Manager）子层采用DataAccess子层和ServiceAccess子层来提供业务需要的基础数据/资源访问能力。

（2）DataAccess子层负责从数据库中存取资源，并向BEM子层屏蔽所有的SQL语句以及数据库类型差异。

DB Adapter子层负责屏蔽数据库类型的差异。

ORM子层负责提供对象－关系映射的功能。

Relation子层提供ORM无法完成的基于关系（Relation）的数据访问功能。

（3）ServiceAccess子层用于以SOA的方式从外部系统获取资源。

注： Service Entrance用于简化对Service的访问，它相当于Service的代理，客户直接使用Service Entrance就可以访问系统发布的服务。Service Entrance为特定的平台（如Java、.Net）提供强类型的接口，内部可能隐藏了复杂的参数类型转换。

（4）ConfigAccess子层用于从配置文件中获取配置object或将配置object保存倒配置文件。

（四）Entity侧层跨越UI/BEM/ResourceManager层

在这些层之间传递数据。Entity侧层中包含三类Entity：

DB Entity，Config Entity和Service Entity。

3.Aspect

Aspect贯穿于系统各层，是系统的横切关注点。通常采用AOP技术来对横切关注点进行建模和实现。

（1）Securtiy Aspect：用于对整个系统的Security提供支持。

（2）ErrorHandling Aspect：整个系统采用一致的错误/异常处理方式。

（3）Log Aspect：用于系统异常、日志记录、业务操作记录等。

4．规则

（1）系统各层次及层内部子层次之间都不得跨层调用。

（2）Entity object 在各个层之间传递数据。

（3）需要在UI层绑定到列表的数据采用基于关系的DataSet传递，除此之外，应该使用Entity object传递数据。

（4）对于每一个数据库表（Table）都有一个DB Entity class与之对应，针对每一个Entity class都会有一个BEM Class与之对应。

（5）有些跨数据库或跨表的操作（如复杂的联合查询）也需要由相应的BEM Class来提供支持。

（6）对于相对简单的系统，可以考虑将Business Function子层和Business Flow 子层合并为一个。

（7）UI层和BL层禁止出现任何SQL语句。

5．错误与异常

异常可以分为系统异常（如网络突然断开）和业务异常（如用户的输入值超出最大范围），业务异常必须被转化为业务执行的结果。

（1）DataAccess层不得向上层隐藏任何异常（该层抛出的异常几乎都是系统异常）。

（2）要明确区分业务执行的结果和系统异常。比如验证用户的合法性，如果对应的用户ID不存在，不应该抛出异常，而是返回（或通过out参数）一个表示验证结果的枚举值，这属于业务执行的结果。但是，如果在从数据库中提取用户信息时，数据库连接突然断开，则应该抛出系统异常。

（3）在有些情况下，BL层应根据业务的需要捕获某些系统异常，并将其转化为业务执行的结果。比如，某个业务要求试探指定的数据库是否可连接，这时BL就需要将数据库连接失败的系统异常转换为业务执行的结果。

（4）UI层(包括Service层)除了从调用BL层的API获取的返回值来查看业务的执行结果外，还需要截获所有的系统异常，并将其解释为友好的错误信息呈现给用户。

6．项目组织目结构

以BAS系统为例。

（1）主目录结构：

（2）命名空间命名：

每个dll的根命名空间即是该dll的名字，如EAS.BL.dll的根命名空间就是EAS.BL。每个根命名空间下面可以根据需求的分类而增加子命名空间，比如，EAS.BL的子空间EAS.BL.Order与EAS.BL.Permission分别处理不同的业务逻辑。

（3）包含众多子项目的庞大项目的物理组织：

（4）核心子项目Core的位置：

Core子项目中包含一些公共的基础设施，如错误处理、权限控制方面等。

7．发布服务与服务回调

以EAS系统为例。

（1）同UI层的Page一样，服务也不允许抛出任何异常，而是应该以返回错误码(int型，1表示成功，其它值表示失败)的形式来表明服务调用出现了错误，如果方法有返回值，则返回值以out参数提供。

（2）如果BAS系统提供了WebService（Remoting）服务，则BAS必须提供BAS.Entrance.dll。 BAS.Entrance.dll封装了与BAS服务交换信息的通信机制，客户系统只要通过BAS.Entrance.dll就可以非常简便地访问BAS 提供的服务。

（3）如果BAS需要通过WebService（Remoting）回调客户系统，则必须提供仅仅定义了接口的BAS.CallBack.dll，客户系统将引用该dll，实现其中的接口，并将其发布为服务，供BAS回调。

（4）当WebService的参数或返回值需要是复杂类型――即架构图中的Service Entity，则Service Entity应该在对应的BAS.EntranceParaDef.dll或BAS.CallBackParaDef.dll中定义。 WebService定义的方法中的复杂类型应该使用Xml字符串代替（注意，Entrance和CallBack接口对应服务的方法的参数是强类型的），而Xml字符串和复杂类型对象之间的转换应当在BAS.Entrance.dll或BAS.CallBack.dll中实现。

三、事件驱动架构 (Event-Driven Architecture)

描述：组件之间通过事件进行通信，事件由事件生成者发布，事件消费者订阅并响应这些事件。
适用场景：高度解耦的系统，如实时数据处理和异步工作流。

优点：高度解耦；易于扩展；提高系统响应性。
缺点：事件追踪和调试困难；复杂事件和错误处理。

实现原理：在事件驱动架构中，组件通过事件进行通信。事件生产者发布事件，而事件消费者订阅并响应这些事件。这种架构允许高度解耦和动态扩展。
例子：实时股票交易系统，其中股票价格更新作为事件发布，交易算法作为事件的消费者。

四、微服务架构 (Microservices Architecture)

描述：将应用程序划分为一组小的、松散耦合的服务，每个服务实现特定的业务功能，并通过轻量级通信机制（通常是 HTTP RESTful API）相互协作。
适用场景：大型复杂应用，需要高度的可扩展性和灵活性。

优点：服务独立部署和扩展；技术栈灵活；促进团队自治。
缺点：开发和管理复杂度增加；服务间通信成本；数据一致性挑战。

实现原理：将复杂应用程序分解为一组小的、独立的服务，每个服务实现特定的功能，并通过轻量级协议（通常是HTTP REST）通信。
例子：视频流平台，每个服务负责一个独立功能，如用户认证、视频编码、推荐等。

五、服务导向架构 (Service-Oriented Architecture, SOA)

描述：强调可复用的服务组件，服务之间通过定义良好的接口和契约（通常使用 SOAP 协议）进行通信。
适用场景：需要大量业务流程整合和服务重用的企业应用。

优点：重用性强；灵活性好；易于集成和替换服务组件。
缺点：性能开销；复杂度高；管理和治理挑战。

实现原理：在SOA中，功能被封装为独立的、可重用的服务，服务之间通过网络调用进行通信，通常使用SOAP或REST协议。
例子：企业级应用，如ERP系统，其中不同的模块（人力资源、财务、库存）作为独立的服务实现。

六、客户端-服务器架构 (Client-Server Architecture)（C/S）

描述：分为客户端（请求服务）和服务器（提供服务）两部分，二者通过网络进行通信。
适用场景：几乎所有的网络应用。

优点：模型简单；易于理解和实施；明确的职责划分。
缺点：服务器瓶颈和单点故障问题；可伸缩性挑战。

实现原理：客户端发送请求到服务器，服务器处理请求并返回响应。这种架构通常涉及到一个服务器和多个客户端。
例子：电子邮件系统，客户端软件用于读写邮件，服务器负责邮件的存储和转发。

七、对等网络架构 (Peer-to-Peer Architecture)

描述：每个节点既是客户端又是服务器，节点之间直接进行资源分享和通信，没有中央服务器。
适用场景：文件共享、加密货币等去中心化应用。

优点：去中心化，提高容错性；可伸缩性强；资源共享效率高。
缺点：管理和安全挑战；性能不可预测；复杂的网络协议。

实现原理：在对等网络中，每个节点既充当客户端又充当服务器，共享资源而无需中心协调器。
例子：BitTorrent文件共享系统，用户分享文件的片段，同时下载其他用户的文件片段。

八、无服务器架构 (Serverless Architecture)

描述：开发者编写的代码运行在无状态的计算容器中，由云服务提供商动态管理机器资源。通常与函数即服务（Function as a Service, FaaS）模式相关联。
适用场景：事件驱动的应用、微服务、快速开发和部署小型服务。

优点：运维负担低；成本根据使用量而定；自动扩展。
缺点：冷启动问题；运行时环境限制；长期成本可能高。

实现原理：开发者编写的函数在完全管理的环境中运行，无需考虑服务器。云提供商根据需求动态分配资源。
例子：网站访问计数器，每次网站被访问时触发一个函数来增加计数器，无需持续运行的服务器。

九、CQRS (Command Query Responsibility Segregation)

描述：将应用程序的操作分为命令（执行操作）和查询（获取数据），使得系统可以更灵活地优化和扩展读写操作。
适用场景：复杂业务逻辑，对读写性能有不同要求的应用。

优点：清晰分离读写操作；提高性能和伸缩性；简化复杂业务逻辑。
缺点：增加系统复杂度；数据一致性挑战；实现成本高。

实现原理：将应用程序的读操作（查询）和写操作（命令）分离，可以独立地优化查询和更新。
例子：电子商务网站，其中商品浏览（查询）和商品购买（命令）通过不同的指令分离操作，提高性能。

十、清洁架构 (Clean Architecture)

描述：通过将软件分解为多个层，每一层只依赖于更内层的策略和概念，从而实现关注点分离，提高系统的可维护性和可测试性。
适用场景：需要长期维护和扩展的大型应用。
微内核架构和分布式架构是软件设计中的另外两种重要架构风格，它们在特定的场景下有着独特的应用和优势。

优点：提高了可维护性和可测试性；关注点分离；独立于框架。
缺点：实现复杂；学习曲线陡峭；可能导致过度工程。

实现原理：清洁架构将系统分为多个层，每一层只依赖于更内层的策略和概念。它强调的是使用依赖倒置原则来分离关注点，使得业务逻辑与外部因素（如数据库和框架）解耦。
例子：在线银行应用，其中核心业务逻辑（如转账和余额查询）独立于外部系统（如数据库和Web服务）。这样，即使更换了数据库或更改了用户界面技术，核心业务逻辑也无需改动。

十一、微内核架构(Microkernel Architecture)

描述：微内核架构区分了基本的系统功能和可扩展的应用功能，核心系统提供最基本的操作，而其他功能则通过插件或模块的形式添加。这种架构的关键在于一个小型的内核负责提供最基础和通用的功能（如低级内存管理、设备驱动等），而更高级的功能（如用户界面、应用程序等）则作为独立的组件或服务存在，这些组件在运行时与微内核通信。
适用场景：

操作系统：许多现代操作系统采用了微内核架构，以便于系统的维护和扩展。
应用软件：需要高度可扩展和可定制的大型软件系统，比如企业级软件，可以根据不同客户的需求添加或修改功能模块。

优点：系统灵活性和可扩展性高；核心逻辑简单，稳定性强。
缺点：插件开发和维护成本高；性能开销；通信复杂度。

实现原理：微内核架构中，系统的核心功能（微内核）提供最基础的操作，而其他功能（如用户界面、设备驱动）作为应用程序或插件运行在微内核之上。这种架构使得系统易于扩展和维护，因为可以独立于核心系统添加或更新功能。
例子：操作系统，如 macOS 和 Windows，它们具有处理基础设备输入输出、内存管理等核心功能的微内核，同时支持用户通过安装软件和驱动来扩展功能。

十二、分布式架构 (Distributed Architecture)

描述：在分布式架构中，系统的不同部分分布在网络上的多个节点上，这些节点协同工作，对外表现为一个统一的系统。分布式架构的关键在于它能够提供高可用性、可扩展性、和容错能力。通过在多台机器上分布运算和存储任务，分布式架构能够处理大量数据和高并发请求。
适用场景：

大数据处理：像 Apache Hadoop 和 Apache Spark 这样的系统就是为了处理分布在多个节点上的大规模数据集而设计的。
微服务：微服务架构通常在分布式环境中实现，每个微服务运行在自己的环境中，相互之间通过网络通信。
云计算和云服务：云平台和服务（如 AWS、Azure、Google Cloud Platform）本质上是分布式架构，提供了各种计算资源和服务。

优点：高可用性和可扩展性；容错性好；资源利用率高。
缺点：开发和测试复杂；网络延迟和数据一致性问题；运维挑战增加。

实现原理：分布式架构通过在网络上分布计算和存储任务到多个物理或虚拟节点来工作，利用这些节点之间的通信和协作来实现系统的整体功能。这种架构的关键是高可用性、可扩展性和容错能力。
例子：云计算平台，如 Amazon Web Services (AWS) 或 Google Cloud Platform (GCP)，它们通过在全球多个数据中心分布资源，为用户提供计算、存储和网络服务。这些服务利用分布式架构的优势，确保了高效率和弹性。

十三、微内核与分布式架构的区别

关注点：微内核架构关注于如何将系统核心功能与高级功能分离，以实现系统的灵活性和可扩展性。分布式架构关注于如何在多个网络节点间分配系统组件，以实现高可用性、可扩展性和容错性。
应用场景：微内核架构多应用于需要高度模块化和可扩展性的系统设计中，而分布式架构则广泛应用于需要处理大量数据和高并发请求的场景。

每种架构风格都有其优势和局限性，选择哪一种架构取决于具体的项目需求、团队的技能以及系统未来的发展方向。

十四、具体架构应用

以下列举几个应用实例：

（一）安卓系统架构

从上图中可以看出，Android系统架构为四层结构，从上层到下层分别是应用程序层、应用程序框架层、系统运行库层以及Linux内核层，分别介绍如下：

1、应用程序层

Android平台不仅仅是操作系统，也包含了许多应用程序，诸如SMS短信客户端程序、电话拨号程序、图片浏览器、Web浏览器等应用程序。这些应用程序都是用Java语言编写的，并且这些应用程序都是可以被开发人员开发的其他应用程序所替换，这点不同于其他手机操作系统固化在系统内部的系统软件，更加灵活和个性化。

2、应用程序框架层

应用程序框架层是我们从事Android开发的基础，很多核心应用程序也是通过这一层来实现其核心功能的，该层简化了组件的重用，开发人员可以直接使用其提供的组件来进行快速的应用程序开发，也可以通过继承而实现个性化的拓展。

（1） Activity Manager（活动管理器）

管理各个应用程序生命周期以及通常的导航回退功能

（2） Window Manager（窗口管理器）

管理所有的窗口程序

（3） Content Provider（内容提供器）

使得不同应用程序之间存取或者分享数据

（4） View System（视图系统）

构建应用程序的基本组件

（5） Notification Manager(通告管理器)

使得应用程序可以在状态栏中显示自定义的提示信息

（6） Package Manager（包管理器）

Android系统内的程序管理

（7）Telephony Manager(电话管理器)

管理所有的移动设备功能

（8）Resource Manager（资源管理器）

提供应用程序使用的各种非代码资源，如本地化字符串、图片、布局文件、颜色文件等

（9）Location Manager(位置管理器)

提供位置服务

（10）XMPP Service（XMPP服务）

提供Google Talk服务

3、系统运行库层

从图中可以看出，系统运行库层可以分成两部分，分别是系统库和Android运行时，分别介绍如下：

（1）系统库

系统库是应用程序框架的支撑，是连接应用程序框架层与Linux内核层的重要纽带。其主要分为如下几个：

Ø Surface Manager：

执行多个应用程序时候，负责管理显示与存取操作间的互动，另外也负责2D绘图与3D绘图进行显示合成。

Ø Media Framework：

多媒体库，基于PacketVideo OpenCore;支持多种常用的音频、视频格式录制和回放，编码格式包括MPEG4、MP3、H.264、AAC、ARM。

Ø SQLite:

小型的关系型数据库引擎

Ø OpenGL|ES：

根据OpenGL ES 1.0API标准实现的3D绘图函数库

Ø FreeType：

提供点阵字与向量字的描绘与显示

Ø WebKit：

一套网页浏览器的软件引擎

Ø SGL：

底层的2D图形渲染引擎

Ø SSL：

在Andorid上通信过程中实现握手

Ø Libc：

从BSD继承来的标准C系统函数库，专门为基于embedded linux的设备定制

（2）Android运行时

Android应用程序时采用Java语言编写，程序在Android运行时中执行，其运行时分为核心库和Dalvik虚拟机两部分。

Ø 核心库

核心库提供了Java语言API中的大多数功能，同时也包含了Android的一些核心API,如android.os、android.net、android.media等等。

Ø Dalvik虚拟机

Android程序不同于J2me程序，每个Android应用程序都有一个专有的进程，并且不是多个程序运行在一个虚拟机中，而是每个Android程序都有一个Dalivik虚拟机的实例，并在该实例中执行。Dalvik虚拟机是一种基于寄存器的Java虚拟机，而不是传统的基于栈的虚拟机，并进行了内存资源使用的优化以及支持多个虚拟机的特点。需要注意的是，不同于J2me,Android程序在虚拟机中执行的并非编译后的字节码，而是通过转换工具dx将Java字节码转成dex格式的中间码。

4、Linux内核层

Android是基于Linux2.6内核，其核心系统服务如安全性、内存管理、进程管理、网路协议以及驱动模型都依赖于Linux内核。

（二）Entity Framework架构

Entity Framework的全称是ADO.NET Entity Framework，是微软开发的基于ADO.NET的ORM(Object/Relational Mapping)框架。

Entity Framework的主要特点：

支持多种数据库（Microsoft SQL Server, Oracle, and DB2）；
强劲的映射引擎，能很好地支持存储过程；
提供Visual Studio集成工具，进行可视化操作；
能够与ASP.NET, WPF, WCF, WCF Data Services进行很好的集成。

架构图一：

架构图二：

（三）企业技术架构

企业技术架构图

该技术架构图是本人根据多年企业技术架构经验而制定，是企业技术的总架构图，希望对CTO们有所借鉴。

简单说明：

中间件基础运行环境是经过统一规划的以WebLogic、JBOSS为主的集群环境；
企业集成平台是以基础业务应用为基础服务于上层平台和基础业务应用的高度集成平台；
数据中心是企业公共数据的集中管理比如用户数据、企业编码，可以通过数据集成平台或服务集成平台分发给其他应用；

（四）总线架构

架构整体图

1、核心是两库一线

　　1.1 接口总线

　　　　所有算法功能抽象成接口,其中大部分接口的方法都是泛型方法,是为了解决某一大类问题的

　　1.2 代码库

　　　　代码库包含现接口总线中接口的各种实现

　　1.3 应用库

　　　　提供用户的界面或者提供给外部的服务，是通过容器配置调用算法库中的代码来实现的各种应用

应用关系图

1、应用通过配置从应用库中组装出自己的应用系统

2、应用本身之外的东西尽量使用拦截器处理(授权访问、权限数据推送、异常处理、缓存、日志等)

3、使用消息队列做高并发应用支撑(秒杀类似应用)

4、使用分布式任务系统做周期作业、数据维护、数据计算等

（五）ENode架构

ENode是一个.NET平台下，纯C#开发的，基于DDD,CQRS,ES,EDA,In-Memory架构风格的，可以帮助开发者开发高并发、高吞吐、可伸缩、可扩展的应用程序的一个应用开发框架。

ENode框架特色

一个DDD开发框架，完美支持基于六边形架构思想的开发
实现CQRS架构思想，并且框架提供C端命令的处理结果的返回，支持同步返回和异步返回
内置Event Sourcing（ES）架构模式，让C端的数据持久化变得通用化
聚合根常驻内存，in-memory domain model
聚合根的处理基于Command Mailbox, Event Mailbox的思想，类似Actor Model, Actor Mailbox
严格遵守聚合内强一致性、聚合之间最终一致性的原则
Group Commit Domain event
基于聚合根ID+事件版本号的唯一索引，实现聚合根的乐观并发控制
框架保证Command的幂等处理
通过聚合根ID对命令或事件进行路由，做到最小的并发冲突、最大的并行处理
消息发送和接收基于分布式消息队列EQueue，支持分布式部署
基于事件驱动架构范式（EDA，Event-Driven Architecture）
基于队列的动态扩容/缩容
EventDB中因为存放的都是不可变的事件，所以水平扩展非常容易，框架可内置支持
支持Process Manager（Saga），以支持一个用户操作跨多个聚合根的业务场景，如订单处理，从而避免分布式事务的使用
ENode实现了CQRS架构面临的大部分技术问题，让开发者可以专注于业务逻辑和业务流程的开发，而无需关心纯技术问题

（六）B/S架构

1、系统安全

这是首要考虑的，以这张图为例，网络划分为3个区：

a) DMZ区可以直接公网访问，也可以与App Core区互通，但不能直接与DB Core区互通 (通常这里放置反向代理Web服务器)

b) App Core区能与DMZ区、DB Core区互通，但是无法直接从公网访问 (通常这里放置应用服务器、中间件服务器之类)

c) DB Core区仅与App Core区互通 (通常这里放置核心数据库)

2、尽量消除单点故障

上图中，除了“硬件负载均衡”节点外，其它节点都可以部署成集群（DB有点特殊，传统RDBMS要实现分布式/集群还是比较困难的，要看具体采用的数据库产品，并非所有数据库都能方便的做Sharding），Jboss本身可以通过Domain模式+mod_cluster实现集群、Redis通过Master/Slave以Sentinel方式可以实现HA、IBM MQ本身就支持集群、FTP Server配合底层储存阵列也可以做到HA、Nginx静态资源服务器自不必说

3、成本

尽量采用开源成熟产品，jboss、redis、nginx、apache、mysql、rabbit MQ都是很好的选择。硬件负载均衡通常成本不低，但是效果明显，如果实在没钱，域名解析采用DNS轮询策略，也能达到类似效果，只不过可靠性略差。

4、Database问题

常规企业应用中，传统关系型数据仍然是主流，但是no-sql经过这几年发展，技术也日渐成熟了，一些非关键数据可以适当采用no-sql数据库，比如：系统日志、报文历史记录这类相对比较独立，而且增长迅速的数据，可以考虑存储到no-sql db甚至HDFS、TFS等分布式开源文件系统中。

如果系统数据量级达到单机RDBMS的上限，尽早考虑Sharding方案，目前mysql在这方面比较成熟，其它数据库就不好说了。

5、性能

web server、app server这些一般都可以通过集群实现横向扩张，满足性能日常增长的需求。最大的障碍还是DB，如果规模真达到了DB的上限，还是考虑换分布式DB或者迁移到“云”上吧。

（七）HBase 系统架构

组成部件说明 　　

Client：

使用HBase RPC机制与HMaster和HRegionServer进行通信

Client与HMaster进行通信进行管理类操作

Client与HRegionServer进行数据读写类操作

Zookeeper：

Zookeeper Quorum存储-ROOT-表地址、HMaster地址

HRegionServer把自己以Ephedral方式注册到Zookeeper中，HMaster随时感知各个HRegionServer的健康状况

Zookeeper避免HMaster单点问题

HMaster：

HMaster没有单点问题，HBase中可以启动多个HMaster，通过Zookeeper的Master Election机制保证总有一个Master在运行　　

主要负责Table和Region的管理工作：　　

管理用户对表的增删改查操作

管理HRegionServer的负载均衡，调整Region分布

Region Split后，负责新Region的分布

在HRegionServer停机后，负责失效HRegionServer上Region迁移

HRegionServer：

HBase中最核心的模块，主要负责响应用户I/O请求，向HDFS文件系统中读写数据

HRegionServer管理一些列HRegion对象；

每个HRegion对应Table中一个Region，HRegion由多个HStore组成；

每个HStore对应Table中一个Column Family的存储；

Column Family就是一个集中的存储单元，故将具有相同IO特性的Column放在一个Column Family会更高效

HStore：

HBase存储的核心。由MemStore和StoreFile组成。

MemStore是Sorted Memory Buffer。用户写入数据的流程：

Client写入 -> 存入MemStore，一直到MemStore满 -> Flush成一个StoreFile，直至增长到一定阈值 -> 触发Compact合并操作 -> 多个StoreFile合并成一个StoreFile，同时进行版本合并和数据删除 -> 当StoreFiles Compact后，逐步形成越来越大的StoreFile -> 单个StoreFile大小超过一定阈值后，触发Split操作，把当前Region Split成2个Region，Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。

由此过程可知，HBase只是增加数据，有所得更新和删除操作，都是在Compact阶段做的，所以，用户写操作只需要进入到内存即可立即返回，从而保证I/O高性能。

HLog ：

引入HLog原因：

在分布式系统环境中，无法避免系统出错或者宕机，一旦HRegionServer意外退出，MemStore中的内存数据就会丢失，引入HLog就是防止这种情况。

工作机制：

每个HRegionServer中都会有一个HLog对象，HLog是一个实现Write Ahead Log的类，每次用户操作写入Memstore的同时，也会写一份数据到HLog文件，HLog文件定期会滚动出新，并删除旧的文件(已持久化到StoreFile中的数据)。当HRegionServer意外终止后，HMaster会通过Zookeeper感知，HMaster首先处理遗留的HLog文件，将不同region的log数据拆分，分别放到相应region目录下，然后再将失效的region重新分配，领取到这些region的HRegionServer在Load Region的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复。

HBase存储格式：

HBase中的所有数据文件都存储在Hadoop HDFS文件系统上，格式主要有两种：　

1 HFile HBase中KeyValue数据的存储格式，HFile是Hadoop的二进制格式文件，实际上StoreFile就是对HFile做了轻量级包装，即StoreFile底层就是HFile ；

2 HLog File，HBase中WAL（Write Ahead Log）的存储格式，物理上是Hadoop的Sequence File；

HFile

图片解释：

HFile文件不定长，长度固定的块只有两个：Trailer和FileInfo；

Trailer中指针指向其他数据块的起始点；

File Info中记录了文件的一些Meta信息，例如：AVG_KEY_LEN, AVG_VALUE_LEN, LAST_KEY, COMPARATOR, MAX_SEQ_ID_KEY等；

Data Index和Meta Index块记录了每个Data块和Meta块的起始点；

Data Block是HBase I/O的基本单元，为了提高效率，HRegionServer中有基于LRU的Block Cache机制；

每个Data块的大小可以在创建一个Table的时候通过参数指定，大号的Block有利于顺序Scan，小号Block利于随机查询；

每个Data块除了开头的Magic以外就是一个个KeyValue对拼接而成, Magic内容就是一些随机数字，目的是防止数据损坏；

HFile里面的每个KeyValue对就是一个简单的byte数组。这个byte数组里面包含了很多项，并且有固定的结构。

KeyLength和ValueLength：两个固定的长度，分别代表Key和Value的长度；

Key部分：Row Length是固定长度的数值，表示RowKey的长度，Row 就是RowKey；

Column Family Length是固定长度的数值，表示Family的长度；

接着就是Column Family，再接着是Qualifier，然后是两个固定长度的数值，表示Time Stamp和Key Type（Put/Delete）；

Value部分没有这么复杂的结构，就是纯粹的二进制数据；

HLog文件就是一个普通的Hadoop Sequence File，Sequence File 的Key是HLogKey对象，HLogKey中记录了写入数据的归属信息，除了table和region名字外，同时还包括 sequence number和timestamp，timestamp是“写入时间”，sequence number的起始值为0，或者是最近一次存入文件系统中sequence number；