2016年很有幸参与了公司内部系统架构3.0的升级,我们把公司的业务进行了四大板块的拆分,分别是应用服务、内容服务、电商服务、支付服务。其他和业务无关的功能拆分到了基础服务,为全公司的业务提供基础服务能力,例如短信、app推送、微信模板消息、图片上传等服务能力。我们还建立我们自己的网关服务,对外提供了统一的服务访问地址。自此之后我对架构的发展和演变也产生了浓厚的兴趣和想法,但是目前接触的有限,与大公司的业务复杂度比还是有很大的差距,一年过去了但是还是想把自己经历的做个总结和自己的想法表达出来,同时也希望大牛们可以指导一番。
备注:“系统架构”是一个很大的范畴,我这里只是把我所经历的小型创业公司的一次架构升级做个分享。
直接上最终的架构图,如下:
上面的架构有什么问题,协议层产生了重度的耦合,协议层耦合各个业务方的逻辑。虽然系统拆分的原则是尽可能的不产生依赖,但是有些还是不可避免的。
三方面:
其次我认为最恐怖的是负责协议层开发的同学被坑了,写透传的代码没技术含量而且是重复性的工作,涉及数据组装的,还得需要简单的了解各个服务逻辑。从而这个协议层就成了耦合的重灾区,所以我根据自己的想法改进了这个架构设计,架构图如下:
然而上面的架构有什么问题?业务服务内部互相依赖,一旦未来服务拆分的粒度越来越细,以及业务的新增,这些依赖就成了一个网状结构,慢慢变的不可维护。接着我改进了这个架构图,再进一步,应该是这样的:
我把之前服务之间直接的互相依赖转变成了统一对中间件的依赖,这样未来再多的服务整个系统架构都是清晰的。
中间件具备的能力:
然而,这里有个最大的问题就是所有压力都集中到了中间件,保证中间件的高可用又成为了一个很大的问题。
除了上述的实际架构是真实的生产环境架构,其他的为我个人目前的想法,目前个人未真实在生产环境实现。最后说说实际踩的坑:
觉得本文对你有帮助?请分享给更多人。