✅ 概述

        技术中台的积累。为项目开发提供可靠保障，工作流，日志，文件存储，邮件等各个功能模块，为新项目开发，提供了基础，降低了开发成本和项目失败的风险。

✅ 微服务开发思想

        采用当前主流的微服务架构。做到风险隔离和业务解耦，大项目变成多个小项目，让项目风险变小和可控。

        微服务的核心特点：
        单一职责：每个服务只负责一个相对独立的业务功能，例如用户服务、订单服务、支付服务。
        独立部署：每个服务可以单独构建、测试和部署，不影响其他服务。
        去中心化：数据和逻辑由各个服务自己管理，而不是集中在单个数据库里。
        轻量通信：服务间通过 API 或消息队列通信，而不是直接调用代码。
        弹性扩展：可以针对瓶颈服务单独扩容，而不是整体扩展。
        技术多样性：不同服务可以使用不同的编程语言、数据库、技术栈。

✅ 技术架构模块图

        技术架构图分三层，前端显示层，后端业务层和最底部的数据存储层。

        在现代软件开发中，分层架构是一种被广泛采用的设计模式。其中最典型的三层结构包括：前端显示层、后端业务层和最底部的数据存储层。这种分层方式不仅有助于系统的清晰设计，也提高了软件的可维护性、可扩展性和可复用性。

        首先，前端显示层是用户与系统交互的窗口。它通常以网页界面、移动应用界面或桌面客户端的形式存在，直接影响用户体验。前端层的主要职责是数据展示和用户输入的采集，它通过直观的界面将复杂的业务逻辑结果呈现给用户。前端有常用的网页，还有移动的APP，小程序，及大屏等方式展示。

        其次，后端业务层是系统的核心。它负责处理前端传来的请求，执行业务逻辑，协调不同模块之间的关系，并与底层数据层交互。后端业务层相当于“系统的大脑”，决定了应用的稳定性和性能。在这一层中，开发者会实现用户认证、权限控制、事务处理、规则校验等功能。同时，依据客户方业务情况，分出多个业务模块，各模块独立开发，达到降低偶合与风险隔离的目的（一个模板开发失败不影响其他模块）。

        最后，数据存储层是系统的基石，负责保存和管理应用所需的数据。常见的存储形式包括关系型数据库（如 MySQL、PostgreSQL）、非关系型数据库（如 MongoDB、Redis），做报表及实时显示的数据库（doris），以及分布式存储系统。数据层不仅需要保障数据的持久化，还要考虑安全性、一致性和高并发访问。在大型应用中，数据库还会进行分库分表、读写分离或使用缓存技术，以确保数据处理的高效与稳定。

        整体而言，这三层架构各自承担了不同的角色，形成了清晰的分工。前端显示层注重用户体验，后端业务层强调逻辑处理，而数据存储层保障信息的长期可用。通过这种分层设计，系统能够在保持高内聚、低耦合的同时，适应快速变化的业务需求，为软件的长期演进提供坚实基础。

✅ 部署结构图

        项目的部署结构。依据项目规模大小，合理制定服务器资源。让性能和成本达到最优。

部署方式	优点	缺点	适用场景
本地部署（On-Premise）	数据可控、安全性高；满足合规要求	硬件投入大，扩展慢，运维成本高	金融、政府、对数据安全/合规要求严格的企业
云部署（Cloud）	弹性扩展、按需付费、上线快	对网络依赖强，可能存在厂商绑定	中小企业、互联网项目、快速上线场景
混合部署（Hybrid）	兼顾安全与灵活性；关键数据留本地，弹性计算上云	架构复杂，运维难度高	既要保证安全又要享受云灵活性的企业
单体应用部署	架构简单，部署快速，维护成本低	扩展性差，升级容易影响整体 小型项目	早期验证性产品
微服务部署	模块独立、扩展性强、容错性好	系统复杂度高，运维和治理成本大	中大型项目、高并发系统
容器化部署（Docker + K8s）	一致性强，跨环境迁移方便，自动扩缩容	学习和运维成本较高	云原生项目、DevOps 成熟团队
Serverless 部署	无需运维，极致弹性，按调用计费	不适合长连接和复杂业务	轻量服务、事件驱动、IoT、函数计算

✅ 项目落地流程（DEVOPS流程）

        项目的落地过程，从需求分析，到技术选型，合理制定开发流程，开发及测试过程规范，保障产品质量。

        采用DevOps项目落地方式，DevOps 项目的目标：
        快速交付：缩短需求到上线的周期。
        持续质量：自动化测试和质量监控。
        高可用：自动化部署、灰度发布、可回滚。
        协作文化：研发、测试、运维、业务一体化。

        DevOps的挑战：
        工具链繁杂，容易盲目上马。
        流水线设计不合理，反而拖慢效率。
        缺乏度量（指标），难以证明价值。

        DevOps的建议：
        从小到大：先选一个试点项目，大项目拆成小项目，一个一个落地。
        自动化优先：从构建/测试/部署三个点突破。
        度量驱动：用 DORA 指标（交付频率、变更失败率、恢复时间、交付周期）衡量效果。
        平台化建设：避免“工具孤岛”，打造统一的 DevOps 平台。搭积木的方式完成整个项目。