每个公司都有后台管理系统,对前端应用的运营进行各种管理。随着管理迭代,功能越来越多,代码量也越来越多,如果是跨团队跨小组或跨业务的同一个后台系统,代码库使用同一个,则将越着时间的迁移,挑战会越来越多:

  1. 同一时间开发分支会很多,如何拉分支,何时合并分支,如何部署各分支的测试,如果没有有经验的研发人员,没有有效的开发规范做约束,则出现代码提交错误,合并错误时,将是一个头疼的事情。
  2. 多团队开发,在公共库的维护和使用上,插件的约束上,能否控制其使用,能否保证公共工具,全局代码的高质量性,保存代码可读性,保证自己的工具不被污染。
  3. 功能越来越多,插件越来越多,启动速度,发布速度,本地变更速度都将变慢
  4. 开发语言,开发框架固定化

以上是实践中确实要面对的问题。而后台管理系统相对前端应用系统有自己的特点,在实践前端微服务化时有天然的优势:后台系统中基本都是按一定模块来开发的,模块间没有什么交互,模块都按统一菜单入口进入,这个特点很适合去做些隔离。那么如何去微服务化?

我先来定义一下我理解的微服务。一个微服务对应的就是一个URL资源服务,该服务是相对内聚的。

如果一个传统的服务是https://www.xxx.com/source/index.html ,其包含账号管理A,商品管理B,数据看板C这三个模块,则以模块来划分微服务时(粒度取决于你,但应该保持一致的最低粒度),

A独立后部署在https://www.xxx.com/source-a/index.html

B独立后部署在https://www.xxx.com/source-b/index.html

C独立后部署在https://www.xxx.com/source-c/index.html

如上所示,则实现了模块微服务化。此时只要将各微服务按一定架构来组织,其入口还保留在https://www.xxx.com/source/index.html (叫根服务吧)这个入口来访问A\B\C三个服务,表面来看是没有区别的,但是感受又是有区别的(也许更快了)。而且技术架构上是可以避免上面提到的困境的。

要实现这个微服务架构,将要面临哪些难题呢,我列举了如下:

  1. 安全。如上所说,每个微服务其实就是一个URL资源,从这来说,URL资源你没办法不让用户单独去访问(即我知道了这个链接,我单独去访问,不从根服务去访问),而后台管理系统一般又都是有权限限制的,如何来做权限控制保证安全(菜单安全、用户信息安全、路径安全、权限安全)
  2. 开发与调试。根服务作为入口,是在不同的一个服务器或端口上,做进行服务A模块开发时,如何进行本地开发和调试,本地如何授权,从根服务如果能进入你本地的服务,那其他模块是否也要走本地服务?

以上问题是否有缺漏,如果你有意见,请提供。

下个回合再一步展开

加客服微信:qmsd3699,开通VIP下载权限!