我的SOA系列《杨过游戏》实践记录，从头到尾给你扒一遍。
为什么非得用SOA？还不是被以前的项目逼的！
我跟你说，之前那个项目，搞得简直是一锅粥，全堆在一起。我改一个按钮的颜色，隔壁老王的代码就炸了，为因为我们都在一套代码里互相踩脚。那会儿我就发誓，再搞项目，必须得拆开，老死不相往来那种。
那段时间刚好看了一些SOA的破文章，吹得神乎其神。我寻思，与其看别人吹，不如自己动手试试，看看到底是个什么牛马。我就想了个最简单的场景，弄个《杨过游戏》，一个很粗糙的文字小游戏，把它的功能全部分开，当成独立的“服务”来跑。
小编温馨提醒：本站只提供游戏介绍，下载游戏请前往89游戏主站，89游戏提供真人恋爱/绅士游戏/3A单机游戏大全，点我立即前往》》》绅士游戏下载专区
杨过游戏的拆分和启动——从三坨屎开始
我立马动手，抓了三个最核心的功能点，当做我的三个服务：
- 角色服务（Character Service）：专门管杨过有多少血、多少内力、等级这些基础数据。
- 包裹服务（Inventory Service）：只管杨过身上有多少东西，几把玄铁剑，几颗九花玉露丸。
- 战斗服务（Combat Service）：只管计算谁打谁掉多少血，纯粹的逻辑计算。
我做的事情，就是把它们彻底隔离开。三个服务，三个独立的运行环境。谁也别想直接访问对方的代码库或者数据库。这是我定的死规矩，比天大。
踩坑与解决——让服务学会“传话”
刚开始我天真地想，让“战斗服务”直接去调用“角色服务”的接口，告诉它：“杨过被打了一下，扣50点血。”结果？屁事没干成，代码来回调用，搞得跟打电话一样，一出问题就全线崩溃，完全是老项目的翻版，气得我差点把键盘砸了。
我赶紧调整，把中间加了个“传话筒”，也就是消息中间件那个东西（别问我用的反正就是一个能让服务互相发消息的盒子）。
我重新设计了流程：
- “战斗服务”只管计算，算完了就扔一个消息：“杨过被扣了50血”。
- “角色服务”？它一直在旁边听着，一听到“杨过被扣了50血”这个消息，它才自己去更新数据库里杨过的血量。
这个改动太关键了！战斗服务计算错了，角色服务顶多血量不对，程序不会崩溃。角色服务写崩了，战斗服务还能正常算下一轮伤害，只是暂时没人接收结果，程序的主体结构稳得很。
遇到的奇葩问题——包裹里的玄铁剑
在这个过程中，我遇到了一个奇葩问题：杨过打怪，战斗服务计算完，消息发出去了，角色服务收到了，一切正常。但打完之后，包裹服务一直没收到杨过获得的战利品信息。
我查了半天，发现我一开始偷懒了。我让战斗服务直接往包裹服务的数据库里写战利品数据（又犯了直接调用的毛病）。
我咬牙切齿地改了：战斗服务只管发消息说：“杨过获得了玄铁剑一把。”包裹服务自己听到这个消息后，才自己去更新自己的包裹记录。当包裹满了，它还会发一个“包裹满了”的消息。这样，谁也管不着谁，但信息是通的。
最终跑起来了——这叫一个舒坦
这套《SOA系列杨过游戏》的架构终于跑起来了，虽然界面丑得跟二十年前的文字MUD游戏似的，但是它的后台是干净的。
现在想改战斗逻辑？我直接去撸“战斗服务”的代码，其他的两个服务看都不用看一眼，它们根本不知道我干了什么，只要我发的消息格式不变就行。想升级杨过的数据模型？我只改“角色服务”。
这感觉，就跟以前在屎山里找代码相比，简直是天堂。虽然过程有点糙，但这种隔离和解耦带来的舒坦，只有自己动手实践过的人才能体会到。这趟折腾，值了！