这几年政企项目里，微服务几乎成了默认架构。但架构选型这件事，跟风容易，落地难。分享五个我们踩过坑后总结的原则。
五条原则
一，按业务域拆分，不按技术拆分，低频模块保持单体——我们见过把"字典管理"也拆成独立服务的项目，纯粹为了拆而拆，运维成本翻倍；二，统一网关、配置中心、日志监控是标配，缺一个后面都难受，这三个组件要在项目前期就搭好，而不是边做边补；三，跨服务事务用本地消息表或 Saga 模式，别硬上分布式事务，最终一致在绝大多数业务场景下足够；四，容器化和流水线自动化，让几百个服务能一键发布、快速回滚；五，服务多了以后，可观测性是生命线——调用链追踪和数据对账机制，出了问题才能查到是哪一环。
什么时候不该用微服务
团队人少、业务简单、迭代要求高的项目，单体能解决的问题别上微服务。我们内部有个朴素的判断标准：如果一个系统的模块数一只手数得过来，先用单体把业务跑通，等复杂度真的上来了再拆。
团队怎么练内功
架构能力的提升没有捷径。我们内部有两个习惯：一是每个季度组织一次架构评审会，把正在进行的项目拿出来集体挑毛病；二是重大故障必须出复盘报告，全团队学习。几年下来，团队对微服务的理解已经从会搭进化到知道什么时候不该用。
单体与微服务的边界在哪
我们的判断标准有三条：团队规模（少于两个开发小组别拆）、业务复杂度（领域边界清晰的系统才适合拆）、交付节奏（需要独立快速迭代的模块优先拆）。三条都不满足就老老实实单体。架构选型是选择题不是填空题，标准答案不存在。
容器化部署的细节
微服务落地绕不开容器化。我们的标准做法：镜像构建进流水线，配置与代码分离，探针必须配齐（存活、就绪、启动），日志统一采集到中央平台。特别提醒两点：一是别把数据库塞进容器跑生产；二是滚动发布必须配健康检查，否则一个坏实例就能拖垮整条链路。
微服务是一套工程体系，不是技术名词。体系没搭好，服务拆得越碎，死得越快。
关于博富特科技
[ "深圳市博富特科技有限公司成立于 2020 年，总部位于广东省深圳市，是一家专注于企业级软件定制开发与数字化解决方案的技术服务商。公司自成立以来，始终坚持以技术为核心、以客户价值为导向，致力于为政企客户提供高质量的软件产品与技术服务，业务覆盖全国。", "公司聚焦定制软件开发、移动应用开发、系统集成、大数据与数据分析、AI 应用开发、IoT 物联网解决方案及信创适配与安全等七大核心方向，服务客户遍及资源回收、智慧城市、政务信息化、企业数字化转型、智慧物流、B2B 交易、跨境贸易及碳资产管理等多个行业领域。" ]
媒体垂询：深圳市博富特科技有限公司 · 19925739956 · zita@szbofute.cn