Sabu：一种面向细分碳排放估算的基于微服务的软件框架

《Environmental Modelling & Software》：Sabu: A microservices-based software framework for disaggregated carbon emissions estimation

　　

Sabu：一种基于微服务（Microservices）的软件框架，用于细分碳排放估算（Disaggregated Carbon Emissions Estimation）。
- 将细分碳估算视为一个软件架构问题。
- 定义了碳估算软件的七个架构属性。
- 提出了Sabu，一个用于碳排放估算工作流的微服务框架。
- 应用微服务基座模式（Microservice Chassis Pattern）以简化服务开发。
- 演示了一个面向建筑的生命周期碳估算微服务。

论文解读

研究背景与问题：全球变暖的严重性已被大量研究证实，准确的碳排放评估对制定有效减缓策略至关重要。现有方法主要聚焦于总碳排放量计算，这限制了其在部门特定行动计划中的应用，因为总量方法掩盖了各部门的详细排放贡献，使针对性干预变得困难。细分碳排放评估需要同时满足区域总体视角和部门详细视角，要求软件能够支持部门级聚合，同时允许细粒度的部门特定计算。然而，该领域面临四项主要挑战：异构数据（Heterogeneous Data）、互操作性（Interoperability）、可扩展性（Scalability）和可维护性（Maintainability）。这些问题从软件设计角度看，本质上属于软件架构（software architecture）问题，而非单纯的环境或能源分析问题。因此，本研究旨在提出一种软件架构解决方案。

研究内容与结论：研究人员将细分碳排放估算视为软件架构问题，定义了七个架构属性（architectural attributes）：数据管理（Data Handling）、通信（Communication）、可扩展性（Scalability）、可扩展性（Extensibility）、模块性（Modularity）、文档（Documentation）和可维护性（Maintainability）。应用这些属性对四种研究机构开发的软件工具进行了结构化观察。基于观察结果，设计了基于微服务（microservices）的软件框架Sabu，该框架将领域工作流组织为独立部署的容器化服务，通过REST API和接口契约进行通信；同时，通过共享库sabu-chassis实现了微服务基座模式（microservice chassis pattern），为日志、请求关联和服务级配置提供可复用支持。最后，通过jug_lca_buildings服务演示了该框架，该服务将建筑隐含碳和生命周期末期碳评估实现为独立服务。结论表明，基于微服务的框架为细分碳排放估算软件提供了有前景的基础，其接口和可维护性措施具体支持互操作性和可维护性，而系统级可扩展性和独立可扩展性留待未来评估。

关键技术方法（不超过250字）：研究人员采用软件架构评估方法，从挑战中提炼出七个架构属性，并基于公开资料对CityBES、CEA、TEASER和URBANopt四种工具进行观察。框架设计采用微服务架构，利用Docker容器化每个服务，以REST API作为通信边界，通过共享库sabu-chassis实现日志、请求关联和配置管理。用例实现了建筑生命周期碳评估服务jug_lca_buildings，其输入数据为蒙特利尔市最多100,000栋建筑的地理空间记录，由jug_gis_cities/mtl_gisoo管道生成；内置数据集包括nrcan_archetypes.json（建筑原型字典）和nrcan_constructions_cap_3.json（建筑构件数据），分别源于NGCI和Seyedabadi等的方法扩展。服务支持直接调用、API访问和Docker容器化三种执行模式，并在单台工作站上评估了运行时间和数值等效性。

研究结果（保留原文小标题）：

**3.2 四种碳排放评估软件工具中的架构属性观察**

**CityBES**：通过公开资料观察，该平台采用分层单体架构，集中式数据库支持异构数据，但内部层间缺乏显式版本化契约；并行模拟支持10³–10⁴栋建筑；可扩展性受CBES SDK限制；模块性高；文档有限且无公开Git仓库；可维护性证据不足。

**CEA**：模块化单体架构，文件型场景目录和中心化InputLocator控制数据访问；内部契约通过数据/工具注册表（schemas.yml、scripts.yml）和内部API实现；提供Docker镜像但手动分片；插件机制支持扩展；文档广泛但架构部分未完成；可维护性中等。

**TEASER**：分层模块化单体，以领域核心为中心；Project API作为统一契约；通过模型简化而非并行实现可扩展性；扩展需修改内部源码；文档分散且架构原理隐式；可维护性中等。

**URBANopt**：模块化分层SDK，gem结构独立版本化；文件型场景和标准模式实现通信；并行化支持到区域规模；可扩展性高；文档全面；可维护性高。

**5. 用例：100,000栋蒙特利尔建筑的隐含碳和生命周期末期碳排放评估**

**服务设计与容器化部署**：jug_lca_buildings封装完整请求-结果流程，API边界通过GeoJSON请求验证，领域计算集中在专用类中；跨关注点由sabu-chassis提供；数据资源打包在服务内，容器部署时工件目录外部挂载，作为独立可部署单元运行。

**数据来源**：输入为最多100,000栋蒙特利尔建筑的地理空间记录，来自jug_gis_cities/mtl_gisoo管道。内置数据集nrcan_archetypes.json由NGCI开发，基于NRCan的BTAP平台；nrcan_constructions_cap_3.json扩展自NGCI工作，由M. R. Seyedabadi根据Seyedabadi等方法框架构建。

**执行模式、性能与数值等效性**：在单工作站（Intel Core i7-10850H，32GB RAM，WSL2）测试，直接调用从1栋0.47秒增至100,000栋5807秒；API模式从0.52秒增至6431秒；Docker API在1000栋时为220秒，表明容器化在本地资源下扩展边界。100栋输入的数值等效性测试中，直接Python与本地REST API结果相同，Docker API平均绝对差为3.82×10^-5 kg CO₂eq，最大绝对差0.001 kg CO₂eq，确认数值等效。

**示例输出与排放结果**：返回记录包含每栋建筑元数据及隐含、生命周期末期和总生命周期排放（kg CO₂eq）；可请求CSV导出。示例中功能代码均为1000（住宅），排放值随建筑尺寸、年代和构造特征显著变化，表明服务能将异构结果序列化为稳定响应格式。

**架构意义与后续步骤**：该用例展示Sabu能将领域工作流封装为有界运行时单元，支持模块性、复用、无状态通信和独立部署。当前容器化大请求模式是扩展边界，下一步将引入批处理机制（约30–50栋为一组），降低资源压力并改善故障隔离。

讨论总结：研究者指出，所识别的挑战本质上是软件架构问题，Sabu通过有界运行时单元、显式接口和职责分离提供了初步基础。微服务基座模式对跨学科研究软件尤为重要，因为它为开发者提供了结构化起点，避免重复实现横切关注点。当前实践初步表明Sabu应对了可维护性挑战，但多服务长期可维护性仍需评估。

结论翻译：本文将细分碳排放估算不仅视为计算或建模问题，还视为软件架构问题。基于该领域障碍，定义了七个架构属性作为评估框架标准；这些属性指导了对四种既有工具的观察。在此基础上，提出了Sabu作为基于微服务的软件框架，并采用微服务基座模式作为服务开发和集成模式。实现的jug_lca_buildings用例表明，既定的生命周期碳工作流可以作为独立、可部署的微服务在该框架内运作。这些贡献支持基于微服务的框架为细分碳排放估算软件提供了有前景的基础；实现的接口和可维护性措施具体支持互操作性和可维护性，而系统级可扩展性和独立可扩展性留待未来评估。