真实生产级云原生微服务项目实战-业务需求、架构设计及技术栈选型

真实生产级云原生微服务项目实战-业务需求、架构设计及技术栈选型

前言
业务需求
数据模型设计
总体架构设计
架构设计思想
技术栈选型
SaaS多租户设计
接口模型设计

前言

本文主要是对 Staffjoy应用的业务需求、数据模型设计、总体架构设计、架构设计思想、还有技术栈选型等做了一个剖析。

面对一个中小规模的业务应用的需求，我们该如何采用微服务架构的思想，将业务领域划分出若干个微服务设计，并给出整体应用架构？

目前技术圈内比较火的Double、Spring Cloud还有Kubernetes都是微服务的主流开发框架或者说平台，我们该如何选型？

在本项目当中，会通过这个 Staffjoy 它的架构和设计作为案例，陆续来回答这些问题。

业务需求

Staffjoy 的主要业务是为小企业提供工时排班(Scheduling)软件解决方案，帮助企业提升雇员管理效率，主要面向零售、餐饮等服务行业。

Staffjoy 应用的业务功能相对简单，简单讲就是帮助小企业管理者管理雇员和排班，并以短信或者邮件等方式，将排班信息及时通知到雇员。

具体讲，Staffjoy 主要支持两类用户角色和用例：

一类是公司管理员(admin)，他们可以通过 Staffjoy 管理公司(company)、员工目录(directory)，团队(team)和雇员(worker)，也可以创建任务(job)，创建和发布班次(shift)信息；
另一类是公司雇员(worker)，他们可以通过 Staffjoy 管理电话和邮件等个人信息，便于接收到对应的排班通知。

Staffjoy 应用主要以共享版 SaaS 服务形式提供，也支持针对一些大客户的定制私有部署，这就要求 Staffjoy 应用易于部署和运维，要支持一键部署到 GKE 等容器云环境。

另外，作为一款 SaaS 服务产品，良好的市场营销(Marketing)和客服是赢得用户的关键，所以 Staffjoy 需要提供营销友好的(Marketing Friendly)宣传和登录页(Landing Page)，也要支持对接主流的在线客服系统如 Intercom。

公示排班（Scheduling）SaaS服务

功能

管理员 Admin 管理公司和排班
雇员 Worker 管理个人信息

非功能

SaaS + 定制部署
一键部署到 Kubernetes 容器云
营销和客服友好（Marketing & Customer Friendly）

数据模型设计

实体关系E-R图

一个 Company 可以有多个 Team
一个 Team 可以有多个 Worker 和 Job
一个 Job 可以有多个 Shift
一个 Shift 一次只能指派给一个 Worker
一个管理员 Account 可以是多个 Company 的 Admin ，可以管理多个公司
一个雇员 Account 只能属于一家公司 Company ，通过 Directory 关联，即雇员不能同时受雇于多个公司。
一个雇员 Account 只能是一个 Team 的 Worker ，不能同时属于多个 Team 。

账户和公司服务数据模型

总体架构设计

其中有两个核心业务服务，一个是Account API(账户服务)，另外一个是Company API(公司服务)。

Account API(账户服务)，提供账户注册、登录认证和账户信息管理等基本功能。
Company API(公司服务)，支持团队(Team)，雇员(Worker)，任务(Job）和班次(Shift)等核心领域概念的管理功能。
Bot REST API(消息转发)，是一个消息转发服务，它一方面作为队列可以缓冲高峰期的大量通知消息，另一方面作为代理可以屏蔽将来可能的通知方式的变更。
Mail Sender 和 SMS Sender，都是消息通知服务，分别支持邮件和短信通知方式，它们可以对接各种云服务，比如阿里云邮件或短信服务。
Who Am I API(Session服务)，支持前端应用获取当前登录用户的详情信息，包括公司和管理员身份，团队信息等，它可以看作是一个用户会话(Session)信息服务。
App(也称 MyCompany)，单页 SPA 应用，是整个 Staffjoy 应用的主界面，公司管理员通过它管理公司、雇员、任务和排班等信息。
MyAccount ，单页 SPA 应用，它主要支持公司雇员管理个人信息，包括邮件和电话等，方便接收排班通知消息。
WWW 应用，是一个前端 MVC 应用，它主要支持产品营销、公司介绍和用户注册登录/登出，这个应用也称为营销站点(Marketing Site)或者登录页(Landing Page)应用。
Faraday(网关)，是一个反向代理(功能类似 nginx)，也可以看作是一个网关(功能类似 zuul)，它是用户访问 Staffjoy 微服务应用的流量入口，它既实现对前端应用和后端 API 的路由访问，也实现登录鉴权和访问控制等安全功能。Faraday 代理是 Staffjoy 微服务架构和前后分离架构的关键，并且它是唯一具有公网 IP 的服务。

架构设计思想

Staffjoy 应用总体架构设计体现了微服务架构设计的三个核心架构设计思想：

分而治之

将大型复杂系统先自顶向下分解为一系列职责单一的子系统和服务，完成每一个子系统服务的设计和实现，再将所有的子系统服务集成起来，可以实现整个应用的完整功能。
分而治之是开发大型分布式系统应对系统复杂性的一般性方法。

单一职责

每一个子系统或者服务，专注某一个功能或者业务领域，职责范围有限受控，易于变更和扩展。
例：Account 服务就管 account 的职责；WWW站点就管产品介绍、登录注册；MyAccount就管雇员账户。每个子模块它的功能职责都比较单一。

关注分离

业务服务(Account,Company) 和技术服务(Faraday,Bot) 、前端服务(SPA,MVC) 和后端 API服务，都是相互分离，也就是关注分离。
让开发团队职责分工清晰，可以实现快速并行交付。
在目前的设计当中，Staffjoy核心领域服务只拆分成两个一个是Account服务，一个是Company服务。拆分的依据是这两个服务具有一定的逻辑独立性，同时考虑到是初创公司团队资源有限，暂时还没有必要拆分出更多的服务，当然如果后续业务起来规模变大了，也可以根据需要进一步拆分。比方说Company服务内部可以按子域可以进一步拆分。

技术栈选型

Staffjoy 微服务间通讯，包括对外暴露 API，全部采用 JSON over HTTP 标准方式。
所有微服务(绿色标注)采用Spring REST开发，有数据访问交互的采用Spring Data JPA，数据库使用MySQL。
WWW 服务使用Spring MVC+Thymeleaf模版引擎开发。
Faraday 也是一个SpringBoot应用，内部路由和安全等逻辑基于Servlet Filter实现。
两个单页 SPA 应用(暗红色标注)都是采用ReactJs+Redux框架开发。
整个应用支持一键部署到本地Docker Compose环境，也支持一键部署到Kubernetes容器云环境，所以 Staffjoy 的整体架构是支持云原生的微服务架构。

技术架构为什么选择 K8s + Spring Boot ：

一是看重社区生态，另一个是对微服务公共关注点考虑的全面性。
综合起来，比较建议：K8s+Spring Boot 。K8s 平台微服务公共关注点考虑非常全面，Spring Boot 开发效率比较高；
这两个都是目前社区的主流，K8s 针对微服务公共关注点，可以认为是最完备的一个解决方案，服务框架只需要 Spring Boot ，因为 Spring Cloud 支持的这些功能，K8s 大部分已经覆盖了。