做Portal计费项目，绕不开一个问题：认证和计费是一套系统还是两套。很多厂家默认推一体化，很多客户又怕绑死。拆还是合没有标准答案，关键看谁在改规则、改的频率高不高、两边要不要同一套口径。先想清楚组织而不是架构，答案自然清晰，别被厂商的默认选项带节奏。
一体化适合规则很少变的场景
如果认证和计费都由同一拨人管，资费半年不动一次，账号来源也单一，一体化最省事。一套系统、一套账号、一次登录，上线快、运维点少。小场所、单门店这类场景，一体化的简洁就是优势，没必要为了架构漂亮拆成两个。一体化还有个隐性好处：认证和计费的会话天然同源，联动不用对接，出账口径不会两边对不上。对这种场景，强拆反而是给自己加活，还得养一套接口。
拆分适合两边各自演进
一旦认证侧要接多种身份源、计费侧要频繁调资费和政策，合在一起就互相拖累。认证升级要等计费发版，计费改规则要动认证配置，迭代节奏被锁死。这时拆开，认证走认证平台、计费走计费引擎，中间用事件和标准接口对接，各自演进互不打扰。拆分后最怕的是接口漂移，两边版本不对齐又出新的对不齐，所以接口要版本化、要契约测试，动一边先跑另一边能过的用例，接口稳了拆分才真自由。
联动靠会话标识不靠定时同步
无论拆合，认证通过和计费开始计时必须是同一条链路上的同一个动作。靠定时任务去刷数据，延迟几分钟就变成对账缺口。正确做法是认证成功推一个上线事件给计费，计费当场建会话。会话标识两边共用，掉线漫游都对应同一笔账，这才是联动的本质，跟系统合不合并没关系。会话标识最好带时间戳和来源，便于事后回溯某次上线是谁、从哪、何时开始的，审计和排障都靠它，不是可有可无的字段。
谁改规则谁就要背口径
拆还是合，最终要看日常谁在动配置。如果计费规则由财务或者运营频繁改，认证由网管管，合在一起每次改计费都要惊动认证侧，权责就乱了。把规则改动收敛到一方，系统形态跟着走。权责清晰，比架构优雅更影响日常稳不稳定。还要写进管理办法：谁有权改哪类规则、改完要不要报备、重大变更要不要灰度，别让一次随手改把整批用户的价格改错，月底才发现全员算贵了。
一体化也有隐藏的锁定成本
一体化省了对接，但绑定深。厂家一涨价你难换，功能迭代跟厂家节奏。选一体化要想清锁定成本，关键功能有没有替代方案、数据能不能全量导出。别为省一点对接费，把命脉交给一家，哪天对方涨价或者停更，你连抽身都难。锁定成本要在选型时算进总拥有成本，不能只看实施报价。
拆分后的接口治理不能省
拆开就要管接口。接口版本、字段变更、向后兼容都要有规矩。一方改了不通知，另一方生产环境就错。接口治理做好了，拆分才真自由；做不好，比合着还乱，因为错误藏在不显眼的字段里。接口要有负责人、有变更评审、有回归用例，三者缺一个，拆分迟早反噬。
共享会话状态怎么存
无论拆合，会话状态要有单一存储，认证写、计费读，不能各存一份然后对。共享存储用可靠中间件，别用本地内存，一重启状态就没。状态单一，联动才不乱，排查时也只有一个真相源，不用两边对账猜谁错了。
组织变动要能回退
今天规则归计费，明天归运营，系统要支持权责切换不重构。配置和权限分离，换人换部门只改授权不改架构。灵活的组织适配，比固定的架构更抗变，业务变你不用重写系统，改授权就行，实施成本低得多。
先做一期再定长期架构形态
拆合别一上来就锁死架构，先做一期跑通核心，观察谁在改规则、改多频繁，再定长期形态。过早定架构，往往和真实组织节奏错配，返工比晚定更贵。一期允许过渡态：先合着快速上线，二期按需拆，演进式比一步到位稳。很多项目一期就上复杂拆分，结果规则半年没变，白养一套接口还多了故障点。架构跟着组织节奏走，不是反过来让组织适应架构，这才是拆合题的题眼。
别用技术潮流替业务决策
看到别家用微服务就觉得自己也该拆，这是用技术潮流替业务决策。拆合回归到谁改规则、改多频繁，潮流不重要。盲目追拆分，团队没那个治理力，反而更乱。决策锚定业务节奏，不被架构时尚带跑，系统才服务业务而不是业务迁就系统。
Portal计费和认证拆还是合，不是技术选型题，是组织题。规则谁改、改多频繁、要不要同一口径，这三个问题答完，答案自然出来。别被厂家的一体化话术带跑，也别为拆分而拆分。适合你的，就是好架构，不用追潮流。