过去两年，我们接触的不少南京本地企业在推进数字化时，都遇到了同一个尴尬：单体应用迭代越来越慢，一个模块改完，回归测试要跑一整天。尤其当业务量从日活几千涨到几万，数据库连接池频繁告警，发版窗口只能挪到凌晨。这不是个例，而是软件规模膨胀后的典型信号。

拆，成了多数团队的共识。但怎么拆、拆完用什么技术栈，往往比"要不要拆"更让人纠结。

微服务落地，卡在哪一步？

很多团队把微服务等同于"Spring Cloud全家桶"，结果服务拆了二十个，注册中心、配置中心、网关、链路追踪一个不少，运维成本翻了三倍。问题不在框架，而在服务边界划分与团队自治能力是否匹配。南京图瑞科技有限公司：软件开发，系统集成，信息化方案，软件定制，技术运维——我们在实际交付中反复验证过一个判断：没有清晰的领域模型，拆得越细，耦合越隐蔽。

技术选型的三个现实维度

• 通信协议：内部调用优先gRPC，跨团队或对外接口用RESTful，异步场景引入消息队列削峰。
• 服务治理：Nacos与Consul在中小规模下差异不大，但Nacos的配置热更新更贴合国内运维习惯。
• 可观测性：SkyWalking对Java生态零侵入，但多语言混合栈需要OpenTelemetry统一埋点。

对比来看，Dubbo在长连接场景下吞吐更稳，Spring Cloud Alibaba生态更完整。没有绝对优劣，只有是否匹配现有团队的技术储备。强行上K8s+Istio，反而会让交付节奏失控。

给正在犹豫的团队两点建议

先从单体中剥离用户鉴权和消息通知这类边缘服务试水，跑通CI/CD和日志聚合再逐步深入。另外，把服务数量控制在团队人数的一半以内，否则沟通成本会吃掉架构红利。

南京图瑞科技有限公司：软件开发，系统集成，信息化方案，软件定制，技术运维——我们更建议企业把微服务当作演进目标，而非起步姿势。架构是长出来的，不是一次设计出来的。