智慧建筑第三方功能集成微服务
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保留
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数据库管理层.
三方数据一般都需要做保存到数据库，这个数据库是一个独立的新的库
CAP的问题； 数据存储问题 按业务划分微服务， 多并发的话，不应该每次都去请求第三方的接口；