文章可能是系列，后续有时间会把项目使用过程中的点滴记录下来，与大家分享和探讨，文中有不妥和不严谨之处支持敬请谅解。

项目背景：项目拿到时是基于Yii的一套微信小程序商城，项目组探讨后，决定尝试使用Swoft进行微服务化，前期项目人员较少，保留原Yii功能和基础组件，仅对新功能使用swoft提供接口服务，等项目发展起来，可将所有功能迁移swoft rpc服务。

先上项目结构草图（非专业架构）：

草图  - 1

您可能会Swoft App && Rpc Call产生疑惑，为什么不用Yii直接调取Swoft Rpc Service呢？

解析：

    确实，在Swoft文档中（https://doc.swoft.org/master/zh-CN/rpc-client/example.html）有讲到可以非swoft框架调用rpc，我考虑了两个问题：

        1、后续引入Api网关，我主要搭建了kong进行测试，是基于http(restful风格)协议，那就归为协议转换。

        2、swoft框架已实现协程，延迟收包功能对于多服务接口调用加快速率等。

        3、swoft已实现服务发现与治理（亲测，无项目经验）。

        4、Event Bus(后面出文章阐述一下我对事件驱动里面的事件总线的理解，不过我对DDD里面说的完全看不懂)的基础放在本层实现。

       注：以上1,2 可能是我个人的误解，希望有api 网关使用经验的朋友可予我分享一下（THX）。

以上是项目的背景和我对项目结构的规划，现在项目已实现网关层和rpc的请求调用，部署了部分接口，对swoft有了大概的了解，大部分还是参考作者demo，不过对rpc接口封装到了vendor中，用单独的git管理interface、breaker、fallback、helper等文件。

红框为服务目录

使用到目前，我对swoft最大的疑问是：为什么RPC的异常没有捕获，所有都在catch中吞噬，返回了500，个人猜测是作者对服务治理的思考，但是参数的Validator也是抛出了500，个人意见不太一致，所以重写了rpc-server/src/ServiceDispatcher.php文件里的dispatch方法，如下：

红框为重写

在红色标识处，我对可知的异常进行了友好处理，返回错误码，而不是模糊的500，这样对扩展的验证器和网关层错误处理更加好控制。不过这个

也许是我个人误解。

以上内容大部分是基于个人理解，也许有很多是因为体系知识不全而产生的误解，大家可在评论留言，共同进步哈。今天算是加班在公司，明天开始放假，提前预祝：端午安康。

第一次写简书，再接再厉！