diff --git "a/blog/DDS/DDS \346\225\260\346\215\256\345\210\206\345\217\221\346\234\215\345\212\241.md" "b/blog/DDS/DDS \346\225\260\346\215\256\345\210\206\345\217\221\346\234\215\345\212\241.md"
new file mode 100644
index 0000000..4d66c4b
--- /dev/null
+++ "b/blog/DDS/DDS \346\225\260\346\215\256\345\210\206\345\217\221\346\234\215\345\212\241.md"	
@@ -0,0 +1,74 @@
+# DDS 数据分发服务
+
+首先我们对DDS的定义进行介绍。
+
+> DDS是一种实时系统的数据分发服务，作为开源的国际化中间件标准，DDS针对实时和嵌入式系统提供了*订阅-分发*的数据沟通方式。
+
+DDS是一个中间件协议和API标准，由OMG（Object Management Group）制定，通过构建虚拟的全局数据池，将应用之间的沟通通过数据池进行连接，不同的应用可以抛弃以往复杂的沟通代码，通过数据池直接读写数据对象。DDS中同时还定义了QoS参数，稳定的架构设计等，保证DDS的稳定性和可靠性。
+
+## DDS功能
+
+#### 中间件 Middleware
+
+在分布式系统中，中间件是存在于操作系统和应用之间的软件层，目的是让系统不同的组件之间能够更加容易地沟通和分享数据。以往开发者可能会耗费大量的精力在于应用之间的信息传递，而通过中间件，开发者只需要关注信息的具体内容，而不是信息传递机制。
+
+![midware](.\images\midware.png)
+
+### 数据中心化的沟通方式
+
+##### 具体方法
+
+处在同一个DDS数据池（DDS Domain）中的应用可以通过数据池进行沟通，定义不同的Topic名称来区分数据，分发者将数据以不同的Topic发送到数据池中，订阅者定义具体的时间和内容过滤器获取需要的Topic内容。不同的数据池相互独立，数据池之间没有数据交换。
+
+![data_centricity](.\images\data_centricity.png)
+
+在很多信息沟通功能的中间件标准和产品中，DDS采用了独特的数据中心的处理方式。大多数的中间件通过在应用和系统之间传递信息实现沟通，而在DDS的数据中心方式下，能够获取到包括上下文信息的所有内容。与传统的信息中心的中间件相比，传统中间件需要定义发送信息的代码，而在DDS中，只需要定义具体的数据分享时间和方式就可以将数据内容分享出来，避免了应用内大量的数据传输相关的代码。
+
+### 全局数据空间
+
+##### 信息定义方式
+
+DDS数据池中，信息分享的单位是Topic中的数据对象。Topic定义了具体的名称和一些‘Key’ 属性，与数据库中的‘key’属性类似。DDS是点对点的沟通方式，不需要通过服务器或者云端来代理。
+
+![global_data_space](.\images\global_data_space.png)
+
+DDS将数据的本地存储称为‘全局数据空间’。在应用的角度来看，全局数据空间像是通过API访问的本地内容，而事实上，DDS发送信息和来更新远程节点上的存储内容，读取方式也与本地存储的类似。
+
+DDS中的存储只是概念上的本地，给应用一种能够访问到整个全局数据空间的假象，事实上，并不存在一个对全部数据进行存储的全局空间，应用只在本地存储需要的内容，而全局数据空间实际上是一系列本地存储的集合。通过全局数据空间，DDS能够在嵌入式、移动端、云端，跨越多种语言，实现低时延的高效沟通方式。
+
+## QoS（Quality of Service）
+
+QoS为DDS提供了可靠性，系统活力和安全性。
+
+在系统做出改变时，中间件动态配置在何处发送哪些数据，自动修改涉及到的部分，如果数据总量很大，DDS能够完成智能过滤和发送终端需要的数据，如果更新需要快速进行，DDS则会发送多播multicast信息来一次性更新数个远程应用。随着数据格式的发展，DDS会跟踪系统不同部分的版本迭代并进行自动转换。如果应用安全性要求较高，DDS将对访问进行控制，强制实施数据流路径，实时数据编码。
+
+DDS的优势在于一个多变且要求很高的环境中，能够高速实现同步修改。
+
+## 动态发现
+
+DDS提供了订阅者和分发者的动态发现，增加了DDS应用的可拓展性。在沟通过程中，应用不需要定义沟通的终点，DDS会去自动发现，这个动态发现的过程实在运行过程中完成的，所以在编译设计阶段不需要考虑，实现DDS应用真正的‘plug-and-play’。
+
+##### DDS 数据池 成员
+
+数据池中应用的本地成员
+
+DDS数据池将应用连接起来，能够彼此交流，代表了一个沟通平台；只有处在同一个数据池中的订阅者和分发者能够完成交流。一个数据池包括了DDS 订阅者，分发者，topics，multitopics和content filtered topics。
+
+动态发现不仅表现在发现订阅者和分发者，还可以发现他们的状态。例如是否正在发送/订阅数据，发送/订阅数据的类型和沟通编码。
+
+DDS中数据池成员可以在同一台机器上，也可以分布在网络中，因为应用使用同样的DDS API进行沟通，不需要了解和配置IP地址，不需要考虑机器的架构不同问题。实现沟通只需要添加额外的沟通成员，而且能够跨越不同的操作系统和硬件平台，减少了工作量。
+
+## 稳定的架构
+
+DDS系统覆盖了从端侧到fog到云端整个流程。在端侧，DDS能够用于实现机器之间的快速，实时沟通，在调解系统中，DDS提供了强健可靠的QoS和以内容为主的信息流。集成了这些系统的DDS，能够为所有过程提供稳定和方位和信息贡献。
+
+![scalable_architecture](.\images\scalable_architecture.png)
+
+OMG DDS 架构从连接到云端的小型设备到大型系统都需要表现稳定，DDS通过衡量数百万个成员，快速传输数据，管理数千个数据对象，提供高可用性和安全性实现IoT服务。DDS简化了分布式系统的开发，抛弃了建立单一标准沟通层的复杂工作。
+
+## 安全性
+
+对于安全性要求较高的场景中，DDS提供了包括安全机制，身份识别，访问控制，机密性和信息分布的完整性保证。DDS分散的点对点架构，能够在不牺牲实时表现的同时提供安全性。
+
+
+
diff --git a/blog/DDS/images/data_centricity.png b/blog/DDS/images/data_centricity.png
new file mode 100644
index 0000000..c60c618
Binary files /dev/null and b/blog/DDS/images/data_centricity.png differ
diff --git a/blog/DDS/images/global_data_space.png b/blog/DDS/images/global_data_space.png
new file mode 100644
index 0000000..737aca7
Binary files /dev/null and b/blog/DDS/images/global_data_space.png differ
diff --git a/blog/DDS/images/midware.png b/blog/DDS/images/midware.png
new file mode 100644
index 0000000..224fe2a
Binary files /dev/null and b/blog/DDS/images/midware.png differ
diff --git a/blog/DDS/images/scalable_architecture.png b/blog/DDS/images/scalable_architecture.png
new file mode 100644
index 0000000..2d66f0c
Binary files /dev/null and b/blog/DDS/images/scalable_architecture.png differ