前言2016年有幸参与公司内部系统架构3.0升级。我们将公司业务拆分为四大板块，即应用服务、内容服务、电子商务服务、付费服务。其他与业务无关的功能拆分为基础服务，为整个公司业务提供基础服务能力，如短信、应用推送、微信模板消息、图片上传等服务能力。我们也搭建了自己的网关服务，对外提供统一的服务访问地址。从那以后，我对架构的发展和演进也产生了浓厚的兴趣和想法，但目前接触的有限，与大公司的业务复杂度相比还有很大的差距。一年过去了，我还是想把自己的经历传递一下。做个总结，说说自己的想法，希望大牛们给予指点。备注：“系统架构”是一个大类。我只是在这里分享我经历过的一家小型创业公司的架构升级。实际的架构直接上最终的架构图，如下：Gateway：EnterpriseServiceBus，对外暴露统一的资源域，并从实际业务中的接口中提取签名认证等一系列认证逻辑，用于网关，随后为未来开通首个第三方服务做准备。协议层：将各个服务的结果进行组装，将http协议请求转化为rpc请求（这里使用phprpc）。业务服务：实际的业务端，各种业务逻辑，如图。基础服务：基础服务能力，与实际业务逻辑无关。理论架构之上的架构有什么问题？协议层产生了严重的耦合，协议层耦合了各个业务方的逻辑。虽然系统拆分的原则是尽量避免依赖，但有些依赖是无法避免的。三个方面：①透传：显然协议层不需要对逻辑做特殊处理，但是协议层又要重新实现代码，增加了工作量②组装：协议层调用各个服务组装后的数据时，它实际上是下意识地涉及了部分业务逻辑③html5应用程序直接调用协议层，并没有真正实现企业总线。其次，我觉得最可怕的是负责协议层开发的同学被骗了。透传的代码没有技术含量，是重复性的工作。如果涉及到数据组装，需要对各个业务逻辑有一个简单的了解。于是，这个协议层就成了耦合的重灾区，于是我按照自己的想法改进了架构设计。架构图如下：改进1：HTML5应用也统一使用网关，HTML5应用的请求执行相应的网关策略。改进二：协议层下移到网关，网关直接进行协议转换。改进三：业务服务直接调用自己依赖的服务，这样我们的服务就可以直接通过网关暴露出来。进一步的架构但是，上面的架构有什么问题呢？业务服务在内部相互依赖。一旦服务拆分的粒度越来越细，未来有新的业务加入，这些依赖就会变成一个网络结构，逐渐变得不可维护。然后我对这个架构图进行了改进，更进一步，应该是这样的：我把之前服务之间的直接相互依赖，变成了对中间件的统一依赖，这样整个系统架构对于以后更多的服务来说就更加清晰了。中间件的能力：同步调用：通过对中间件的调用，直接调用服务异步调用：通过对中间件的调用，完成对服务的异步调用但是，这里最大的问题是，所有的压力都集中到了中间件，保证中间件的高可用成为一个大问题。结论除了上面的实际架构是真实的生产环境架构外，其他都是我目前的想法，目前还没有真正在生产环境中实现过。最后说一下实际的坑：服务超时：网关设置了熔断时间，导致终端请求服务刚提交交易导致数据一致性问题。再比如，短信刚发送成功，请求中断，客户端返回失败，但短信确实收到了。分布式事务：跨服务调用让事务提交不再像以前那么简单。如果开发人员少，一个人会维护多个项目，增加了部署的难度。跟踪问题难度更大（我们引入了requestId来跟踪整个链接的调用过程）EasyPHP：极速轻量的PHP全栈框架扫描下方二维码关注我的技术公众号，分享我的原创技术及时为大家
