commit 1ebcdbe9da6afd78ded6aa28b83797878eacb458
Author: 刘鑫 <lxxh1992@163.com>
Date:   Thu Aug 7 14:15:52 2025 +0800

    更新 'Home智慧建筑第三方功能集成微服务'

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
new file mode 100644
index 0000000..8b3fffc
--- /dev/null
+++ 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
@@ -0,0 +1,63 @@
+智慧建筑第三方功能集成微服务
+1.目的和划分
+为了保持智慧建筑平台的单纯性，同时也为了保持代码的开闭原则，避免每部署一个客户项目，就修改之前的代码，导致代码过度膨胀；同时也为了解耦，保持平台独立性和第三方的可配置性；
+该微服务划分模式，可以在一个微服务集成所有的第三方厂商和业务，也可以按照业务区分的划分，第一个的好处是开发简单省事，第二个的问题是耦合过重，牵扯过重，服务一挂所有的第三方都得挂，更新也需要全部停机更新，坏处是开发繁琐，比第一种消耗时间；
+选择按不同业务做不同的微服务；
+2.技术结构
+1..Net8作为整个平台的主语言；
+2.MySQL作为数据库；
+3.Autofac做为依赖注入；
+4.集成容器化，
+5.Gateway作为网关；
+6.RESTful API风格；
+7.跨服务调用gRPC可选；
+8.消息队列RabbitMQ 或 Kafka可选；
+9.缓存Redis可选；
+10.NLog做日志（使用平台目前的方式）
+11.Polly 策略（后期可选，熔断重试操作）
+12.调用方式：微服务http、静态dll/nuget包
+13.部署k8s/或者Aspire
+14.项目框架：自定义DDD形式，
+15.CAP保留
+16.
+3.注意事项
+1.性能；
+2.一定的并发性；
+3.微服务的无状态性；
+4.缓存；
+5.Sdk厂商中涉及到的句柄或token，避免覆盖；
+6.涉及到有状态的第三方链接的话，可以用缓存记录，然后第三方要用到的东西从缓存中通过key 取，让状态给到调用方。
+
+
+
+4.采用DDD+Aspire的优势
+1.DDD的边界明确，逻辑直观可控；
+2.开发过程简单；
+3.扩展性强；
+4.耦合低；
+5.流行适用
+6.Aspire可以做微服务编排，直接集成发现所有微服务，在没有k8s的时候，可选；
+7.微软出的，更实用；
+5.代码分层说明
+5.1网关层
+Ocelot：轻量，配置简单，统一入口；
+5.2WeiCloud.Utils工具层
+WeiCloud.Utils：利用现有的V4的工具层；
+5.3Aspire微服务统一发现层（可选）
+Aspire：利用微软提供的Aspire做微服务的统一发编排，简单；
+5.4DDD的Entities实体层
+包含该微服务的枚举、实体、领域模型等；
+5.5 Web API 层
+对外调用的控制器层；
+5.6DomainService服务层
+定义服务接口和服务实现类；
+5.7Dto的Domain层（可选）
+定义涉及到的dto，可以通过AutoMapper做映射，也可以不用，可选；
+5.8Store数据库管理层.
+三方数据一般都需要做保存到数据库，这个数据库是一个独立的新的库
+![](https://) 
+
+CAP的问题；
+数据存储问题
+按业务划分微服务，
+多并发的话，不应该每次都去请求第三方的接口；