1. SOA概述：从单体架构到SOA的演进

1.1 为什么我们要谈架构演进？

说实话，我刚入行那会儿，做新能源项目最头疼的就是系统耦合。一个充电桩管理平台，充电、计费、监控全揉在一起。改个计费逻辑，充电模块就得跟着重新部署。你想想看，这得多痛苦？

后来我慢慢意识到，这不是代码的问题，是架构的问题。今天我们就从最基础的开始聊——单体架构到SOA的演进。

1.2 单体架构：曾经的“万能药”

单体架构，说白了就是把所有功能都塞进一个进程里。用户管理、订单处理、设备监控……全在一个大包里。

单体架构的特点：

  • 开发简单，初期上手快
  • 部署方便，一个包搞定
  • 测试容易，本地就能跑

但问题也来了。我记得2018年做一个储能系统，单体架构下，业务量一上来，整个系统就卡死。为什么？因为所有模块共享内存和线程池，一个模块出问题，全盘崩溃。

我曾经踩过的坑：单体架构下，充电桩的通信模块因为内存泄漏挂了，结果计费模块也跟着宕机。用户充完电发现扣费失败，投诉电话打爆了。从那以后，我再也不敢把所有鸡蛋放一个篮子里。

1.3 SOA：服务化的觉醒

SOA（面向服务架构）的出现，说白了就是要把大系统拆成小服务。每个服务独立部署、独立运行、独立扩展。

SOA的核心三要素：

要素 说明 我项目中的例子
服务 可独立运行的业务功能单元 充电桩状态服务、用户认证服务
契约 服务间通信的接口规范 WSDL、OpenAPI 定义
协议 服务间交互的通信规则 SOAP、REST、gRPC

我个人习惯把这三个要素比作“快递服务”：

  • 服务 = 快递员（独立干活）
  • 契约 = 快递单（写清楚收件人、地址）
  • 协议 = 快递流程（怎么揽件、怎么派送）

1.4 服务：SOA的最小单元

服务是什么？不是随便拆个函数就叫服务。我建议你记住这句话：服务是自治的、可复用的业务能力单元。

举个例子，在新能源项目中：

// 不好的服务设计
public class ChargingService {
    public void processCharging(String userId, String pileId, double amount) {
        // 这里既做认证，又做计费，还做设备控制
    }
}

// 好的服务设计
// 认证服务
public class AuthService {
    public boolean authenticate(String userId) { ... }
}

// 计费服务
public class BillingService {
    public double calculateFee(String userId, double amount) { ... }
}

// 设备控制服务
public class DeviceService {
    public boolean startCharging(String pileId) { ... }
}

你看，拆开之后，每个服务只干一件事。认证服务挂了，不影响充电。这就是SOA的魅力。

1.5 契约：服务间的“君子协定”

契约，说白了就是服务之间怎么打招呼。我建议你用OpenAPI（以前叫Swagger）来定义RESTful接口，或者用Protobuf定义gRPC接口。

我的经验：契约一定要版本化。我曾经因为没给接口加版本号，导致充电桩固件升级后，老桩和新服务对不上，整整排查了两天。现在我的每个服务接口都带v1、v2前缀。

1.6 协议：通信的“交通规则”

协议决定了服务之间怎么传数据。新能源场景下，我常用的协议有：

  • RESTful HTTP：适合查询类、管理类接口，简单直观
  • gRPC：适合高频、低延迟的通信，比如充电桩实时状态上报
  • MQTT：适合物联网设备，比如充电桩的远程控制

嗯，这里要注意：不要为了用协议而用协议。我见过有人用gRPC做用户登录，其实HTTP完全够用。选协议要看场景，不是看潮流。

1.7 SOA在新能源领域的价值

说了这么多，SOA到底能给新能源带来什么？我总结了几点：

SOA在新能源的四大价值：

  1. 系统解耦：充电、储能、光伏各自独立，互不影响
  2. 弹性扩展：充电桩多了，只扩展充电服务，不用动别的
  3. 技术异构：计费用Java，设备控制用Go，各取所长
  4. 快速迭代：改一个服务不影响全局，上线风险低

我记得去年做一个光储充一体化项目，客户要求三个月内上线。如果还是单体架构，根本不可能。但用了SOA，我们同时开了三个团队并行开发——充电团队、储能团队、光伏团队，各干各的，最后集成只花了一周。

避坑指南：SOA不是银弹。如果团队小、业务简单，强行上SOA反而增加复杂度。我建议：先单体，后拆分。等业务复杂度上来了，再逐步服务化。

1.8 小结

今天我们从单体架构聊到了SOA，核心就三件事：

  • 服务：独立、自治、可复用
  • 契约：接口规范、版本管理
  • 协议：选对通信方式，别乱用

下一章，我会带你深入SOA的服务设计原则，聊聊怎么把服务拆得“刚刚好”。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →