[讨论] 春松客服架构升级 – 前后端分离 – 船长

我们为什么要做前后端分离？

在重客户端应用或由极少人进行维护的项目，我们可以把前端界面化和后端业务逻辑结合在一起。

比较成熟的开发框架：e.g. Python Flask Django

• 什么是前端： 与用户接触的部分，界面呈现部分
• 什么是后端： 着重业务逻辑处理，以及与外部系统交互

实际上，当我们想将一个软件应用在生产环境时，必须要考虑随着业务发展，该软件服务的业务稳定性要求 功能迭代需求。

目前春松客服的项目架构的现状是： 单体应用、前后端一体。

但对我们来讲，目前最重要的是

exclamation::exclamation:解决单体应用的瓶颈问题 :exclamation::exclamation:
一旦可以解决单体问题，我们就具备了横向扩容的能力，也就可以避免单点故障，这很重要。

真正意义上的分离是什么？

我们真正要做的是 "以服务为模块化进行拆分"，保证系统的生产可用性和稳定性要求。

不要过分拆分，拆分太细会导致服务的稳定性问题。

我们要做什么？

前端

• 前端需要自行迭代，支持对界面的自定义，包含样式调整；替换 资源 等； 这些没必要依赖业务后端的支持，可以自行发展和演进
• 插件式系统架构 对前端的模块化要求，定义插件的页面标准；插件模块的资源动态加载

后端

• 业务逻辑模块清晰，性能的稳定性支持

开源

• 代码结构清晰，对开发者友好，吸引更多的人加入
• 三方模块开发友好，不用与主体业务代码耦合

标准与规范

作为主导的开源团队，我们在业务实现上做的事情应该是尽可能的简单和稳定；更多时间应该用在标准和框架的制定。

我们希望打造的是一个像是 Kubernetes 的一个模块化的平台。

核心功能模块