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

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

前言

本文主要是对 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 大部分已经覆盖了。

SaaS多租户设计

Staffjoy是一个支持多租户的SaaS应用，普通用户可以在Staffjoy上注册一个账户，首次注册的时候，会提示创建公司 Company。完成以后，该用户自动成为该公司的管理员，之后这个管理员用户登录app就可以管理对应公司的雇员、任务和排班信息。

Staffjoy采用共享数据库的逻辑隔离机制，每一个company是一个逻辑隔离的单位。每一个公司管理员只能管理自己的Company 公司的信息，雇员也只能管理自己的个人信息。

用户访问Staffjoy应用的时候，首先，Faraday网关会对用户进行登录鉴权；其次，服务之间调用也有相应的身份鉴权机制，来保证用户和公司的数据的隔离性和安全性。关于具体多租户实现机制，我们在后续的数据模型设计和框架设计部分还会进一步展开。

接口模型设计

账户Account服务接口模型

公司Company服务接口模型

公司管理员Admin服务接口模型

员工目录Directory服务接口模型

团队Team服务接口模型

雇员Worker服务接口模型

任务Job服务接口模型

班次Shift服务接口模型

公众号

参考

《Spring Boot 与 Kubernetes 云原生微服务实践 ～ 全面掌握云原生应用的架构设计与实现》 杨波