电商架构回顾之一V1.0版本
前言
这篇文章主要是简单介绍一下,我刚进公司见到的电商V1.0架构。
部署架构图
V1.0电商服务架构.png电商架构剖析
简介
整个电商架构是基于微服务架构体系搭建,核心组件主要包括SpringCloud Gateway、Consul、Java Application、PHP Application、 Mysql五大部分组成。前端接口业务和后台管理业务独立部署的两套架构,整体部署架构无太大差异,差异主要在前端接口业务入口使用腾讯云SLB进行负载均衡,请求分发;而后台服务独立部署了nginx来进行请求反向代理。
微服务组件
负载均衡
直接使用腾讯云提供的负载均衡SLB集群服务。
网关
服务网关采用了SpringCloud新推出的Gateway组件,Gateway组件是2018年2月发布的,基于SpringBoot 2.0,Spring 5.0,支持非阻塞、异步编程模式。性能上比Netflix ZUUL更优秀(因为ZUUL采用同步阻塞编程模型)。
基于Gateway提供的filter链功能,定制开发了jwt token的接口鉴权、url访问级别控制(如:/pub前缀直接放行、/user需要判断token合法性等)。
为什么会选择Gateway?
究其原因,还是觉得是基于SpringCloud的(易上手),然后采用了非阻塞、异步模型(性能有保障)。But... ,在真实的使用过程中,你会发现一个新出来的东西,未经过长时间实践检验的情况下,会让你踩多少坑。
服务注册/发现
服务注册/发现采用Golang实现的Consul框架,Consul提供了很多特性,例如HTTP API、KV存储、支持多语言、支持多数据中心等。
SpringCloud提供Consul Client的SDK,直接集成到项目后,项目启动过程中就能自动完成服务注册,服务发现同样使用起来非常方便,通过feign就能完成服务调用。
Consul提供两种服务注册的方式,通过HTTP API或者通过JSON配置文件。Java应用通过SDK封装了HTTP API的方式来完成服务注册,Php应用则是通过配置JSON文件的方式完成服务注册的。
Consul服务注册有两种方式:HTTP API & JSON配置文件
方式一:HTTP API
http://{ip}:8500/v1/agent/service/register/:service
方式二:JSON 配置文件
{
"services": [
{
"id": "serverId",
"name": "serverName",
"tags": [
"primary"
],
"address": "127.0.0.1",
"port": 9003,
"checks": [
{
"id": "api-servie",
"name": "Service 'xx' check",
"http": "http://127.0.0.1:9003/public/health",
"method": "GET",
"interval": "10s",
"timeout": "1s"
}
]
}
]}
启动Consul增加启动参数-config-dir
nohup ./consul agent -dev -config-dir=/consul-conf/service.json &
为什么会选择Consul?
性能高,微服务大了,能顶住访问量; 保证数据强一致性,不会出现数据不一致情况下服务调用到不可用的节点。还提供KV存储,还能当个简单的配置中心使用。
总结
对业务刚起步,同时又想实践微服务架构的初创公司来说,这套V1.0架构没啥毛病,玩得好好的,但是当用户访问量突然暴增的上来,这套架构就会遇到坑了,这时候技术架构就需要作出了相应的调整了。