云时代架构首先要理解什么是云计算,根据 NIST(美国国家标准与技术研究院)以及微软、IBM、阿里云等对云计算定义为三种服务模式,LaaS(Infrastructure as a Service 基础设施即服务)、PaaS(Platform as a Service 平台即服务)、SaaS(Software as a Service 软件即服务)。
客户端是 vue、react 为主 pc/h5 页面和小程序客户端、安卓、ios 客户端,以及开放给第三方 open API SDK。
网关是所有服务的统一和唯一 API 请求入口,拥有负载均衡、验证权限、分流请求、熔断请求、监控请求、公共服务统一逻辑处理等,网关组件往往会搭配 oauth2 作为登录授权验证,用户权限验证,搭配 erueka 作为 API 接口服务注册和发现,搭配 apollo 作为配置中心。可以发现下图中蓝色部分都是 PaaS 层定义平台组件部分,这些组件承担系统中公用和部分非业务逻辑事情。
中台 API 可以理解为宏流程模型具体实现代码,关注的整个宏流程模型的具体实现,例如中台 API 中有一个【外卖平台商品管理 API】接口,这个 API 做了外卖平台接口封装,调用这个接口就可以完成三个平台的商品管理。因为这个接口实现宏流程模型,除了基本的商品管理新增、修改、删除外不包含其他的业务逻辑。
这个时候有一个需求需要在客户添加商品成功后推荐类似商品给客户继续添加,这个具体的业务逻辑应该写在【前台业务】中,而不是中台 API 中。因为这个业务逻辑不是宏流程模型中的逻辑,不符合通用业务标准,同时也无法直接复用,因为推荐选项可能是商品类目推荐、也可能是商品名称相似推荐。
如果这个推荐业务上线后受到客户欢迎,是可以考虑纳入中台 API 中的。但是不应该修改宏流程模型,因为推荐不属于外卖平台管理的行业标准,准确来说这个属于数据中台的推荐能力,应该纳入数据中台中实现推荐 API。如果没有建设数据中台,那可以考虑新增一个中台推荐 API 模块,再修改【前台业务】把原有逻辑改为调用中台推荐 API 逻辑即可完成,这样中台推荐 API 成为可复用的能力。
通过前台业务和中台 API,即业务和领域模型逻辑分离,做到中台 API 的稳定性、复用性大大提高,前台业务具备快速响应市场变化和低成本试错能力。
市场变化会直接影响系统的稳定性/可用性,首先是流量变化,当某一模块面对高涨流量时通过容器技术很容易建立多节点应对,例如美团外卖订单量这天指数级增加带来超出现有订单系统能承受最大峰值,我们可以通过 kubernets kubectl 快速新增一个订单中台模块 pod 节点,通过网关动态调整应对峰值流量,当流量下降后我们可以删除掉新增这个 pod 节点,做到需要时实例化,不需要就删除,不会浪费资源和成本。
其次是创新业务低成本试错,很多时候我们会尝试进入其他行业或热门市场中,需要产品研发团队能快速响应需求开发和上线,项目需要控制整个投入成本,例如是对业务基础上进行微创新,只需要多启动一个 pod 节点做前台业务实现,剩下复用中台接口 API。如果是全新项目没有可复用的,我们同样是启动 pod 节点,部署需要的平台组件和前台业务实现,成为一个独立的系统环境,后期就算失败也可以快速注销掉,不会影响其他系统。
作者勘误,laas应该是iaas。