2016年很有幸参与了公司内部系统架构3.0的升级，我们把公司的业务进行了四大板块的拆分，分别是应用服务、内容服务、电商服务、支付服务。其他和业务无关的功能拆分到了基础服务，为全公司的业务提供基础服务能力，例如短信、app推送、微信模板消息、图片上传等服务能力。我们还建立我们自己的网关服务，对外提供了统一的服务访问地址。自此之后我对架构的发展和演变也产生了浓厚的兴趣和想法，但是目前接触的有限，与大公司的业务复杂度比还是有很大的差距，一年过去了但是还是想把自己经历的做个总结和自己的想法表达出来，同时也希望大牛们可以指导一番。
备注：“系统架构”是一个很大的范畴，我这里只是把我所经历的小型创业公司的一次架构升级做个分享。
实际架构
直接上最终的架构图，如下：
- 网关: 企业服务总线，对外暴露统一的资源域，把实际业务中接口中都涉及签名鉴权等一系列鉴权逻辑抽到网关，其次为未来开放第三方服务准备。
- 协议层: 组装各个服务的结果，把http协议的请求转换成rpc请求(这里我们使用的是phprpc)。
- 业务服务: 实际的业务方，各种商业逻辑，如图所示。
- 基础服务: 基础服务能力，和实际商业逻辑无关。
理论架构
上面的架构有什么问题，协议层产生了重度的耦合，协议层耦合各个业务方的逻辑。虽然系统拆分的原则是尽可能的不产生依赖，但是有些还是不可避免的。
三方面：
- ①透传：明明协议层不需对逻辑做特殊的处理，协议层却要实现一遍代码，增加了工作量
- ②组装：协议层调用各个服务的组装数据的时候，其实还是下意识涉及了部分业务逻辑
- ③html5应用直接调用了协议层，没有正真的实现企业总线
其次我认为最恐怖的是负责协议层开发的同学被坑了，写透传的代码没技术含量而且是重复性的工作，涉及数据组装的，还得需要简单的了解各个服务逻辑。从而这个协议层就成了耦合的重灾区，所以我根据自己的想法改进了这个架构设计，架构图如下：
- 改进一：html5应用也统一走网关，html5应用的请求执行对应的网关策略
- 改进二：下移协议层到网关，网关直接进行协议转化
- 改进三：业务服务直接调用所依赖的服务，这样我们的服务就可以业务直接通过网关暴露出去
更进一步的架构
然而上面的架构有什么问题？业务服务内部互相依赖，一旦未来服务拆分的粒度越来越细，以及业务的新增，这些依赖就成了一个网状结构，慢慢变的不可维护。接着我改进了这个架构图，再进一步，应该是这样的：
我把之前服务之间直接的互相依赖转变成了统一对中间件的依赖，这样未来再多的服务整个系统架构都是清晰的。
中间件具备的能力：
- 同步调用：直接通过对中间件的调用完成对服务的直接调用
- 异步调用：通过对中间件的调用完成对服务的异步调用
然而，这里有个最大的问题就是所有压力都集中到了中间件，保证中间件的高可用又成为了一个很大的问题。
结语
除了上述的实际架构是真实的生产环境架构，其他的为我个人目前的想法，目前个人未真实在生产环境实现。最后说说实际踩的坑：
- 服务超时：网关设置了熔断时间，导致服务刚提交事务却被终端请求导致的数据一致性问题。再例如，刚发送短信成功，却被中断请求，客户端返回失败，实际却接收到短信。
- 分布式事务：跨服务调用使得事务的提交不像以前那么简单
- 如果开发人少，导致一个人维护多个项目
- 增加了部署难度
- 追踪问题难度加深(我们引入了requestId追踪整个链路的调用过程)