diff --git a/Home%E6%99%BA%E6%85%A7%E5%BB%BA%E7%AD%91%E7%AC%AC%E4%B8%89%E6%96%B9%E5%8A%9F%E8%83%BD%E9%9B%86%E6%88%90%E5%BE%AE%E6%9C%8D%E5%8A%A1.md b/Home%E6%99%BA%E6%85%A7%E5%BB%BA%E7%AD%91%E7%AC%AC%E4%B8%89%E6%96%B9%E5%8A%9F%E8%83%BD%E9%9B%86%E6%88%90%E5%BE%AE%E6%9C%8D%E5%8A%A1.md
index 8b3fffc..43d1bbb 100644
--- a/Home%E6%99%BA%E6%85%A7%E5%BB%BA%E7%AD%91%E7%AC%AC%E4%B8%89%E6%96%B9%E5%8A%9F%E8%83%BD%E9%9B%86%E6%88%90%E5%BE%AE%E6%9C%8D%E5%8A%A1.md
+++ b/Home%E6%99%BA%E6%85%A7%E5%BB%BA%E7%AD%91%E7%AC%AC%E4%B8%89%E6%96%B9%E5%8A%9F%E8%83%BD%E9%9B%86%E6%88%90%E5%BE%AE%E6%9C%8D%E5%8A%A1.md
@@ -1,9 +1,13 @@
 智慧建筑第三方功能集成微服务
+
 1.目的和划分
+
 为了保持智慧建筑平台的单纯性，同时也为了保持代码的开闭原则，避免每部署一个客户项目，就修改之前的代码，导致代码过度膨胀；同时也为了解耦，保持平台独立性和第三方的可配置性；
 该微服务划分模式，可以在一个微服务集成所有的第三方厂商和业务，也可以按照业务区分的划分，第一个的好处是开发简单省事，第二个的问题是耦合过重，牵扯过重，服务一挂所有的第三方都得挂，更新也需要全部停机更新，坏处是开发繁琐，比第一种消耗时间；
 选择按不同业务做不同的微服务；
+
 2.技术结构
+
 1..Net8作为整个平台的主语言；
 2.MySQL作为数据库；
 3.Autofac做为依赖注入；
@@ -19,8 +23,10 @@
 13.部署k8s/或者Aspire
 14.项目框架：自定义DDD形式，
 15.CAP保留
-16.
+
+
 3.注意事项
+
 1.性能；
 2.一定的并发性；
 3.微服务的无状态性；
@@ -29,8 +35,8 @@
 6.涉及到有状态的第三方链接的话，可以用缓存记录，然后第三方要用到的东西从缓存中通过key 取，让状态给到调用方。
 
 
-
 4.采用DDD+Aspire的优势
+
 1.DDD的边界明确，逻辑直观可控；
 2.开发过程简单；
 3.扩展性强；
@@ -38,7 +44,9 @@
 5.流行适用
 6.Aspire可以做微服务编排，直接集成发现所有微服务，在没有k8s的时候，可选；
 7.微软出的，更实用；
+
 5.代码分层说明
+
 5.1网关层
 Ocelot：轻量，配置简单，统一入口；
 5.2WeiCloud.Utils工具层
@@ -57,6 +65,7 @@ Aspire：利用微软提供的Aspire做微服务的统一发编排，简单；
 三方数据一般都需要做保存到数据库，这个数据库是一个独立的新的库
 ![](https://) 
 
+
 CAP的问题；
 数据存储问题
 按业务划分微服务，