按上述分析看,前后端是非常适合拆开的。在云计算时代到来之前,即移动互联网时代,为了跨终端,前后端分离就已经开始流行了,应该说有比较成熟的用户基础了。同时,从前后端分离架构的逻辑、过程等视图看,这套方案相对简单,容易上手,非常适合作为微服务化改造的第一步。 在此方案中,我们只需要引入接入层网关和开发框架(SpringBoot) ,前者用于承载前端组件,后者降低开发难度。接入层网关,通常以Nginx、OpenRestry、Kong等开源中间件为基础扩展,支持从服务治理平台接收控制指令,实现前端热发布和页面级灰度。另外,利用中间件本身的插件机制来实现业务需求定制。
-
前端组件可以采用React、Vue等框架开发,发布时将HTML/CSS/JS等静态资源打成ZIP包。
-
后端组件将服务封装成HTTP RESTful API,发布时打成特定的压缩包,例如: FatJAR、 WAR等。
-
前端以AJAX方式调用后端服务,报文采用JSON格式编码。
-
接入层网关会对客户端(浏览器)的请求做路由转发,静态资源请求在本地处理,动态服务请求转给后端。
分步骤演进至全微服务架构
============
俗话说万事开头难,将前后端分离作为切入点,我们可以轻松地开启微服务化改造之旅。接下来,我们如何一步步趋近至全微服务架构呢?以JAVA领域为例,如下图所示,典型的微服务架构主要包含下列组件:
-
接入层网关,负责将流量落地并对其进行安全检测,然后分流静态和动态请求。另外,前端组件的静态资源会部署在它里面。常见的开源产品有: Nginx. OpenRestry、 Kong等。
-
应用开发框架,用于措建应用的骨架,例如: Spring Boot。历经十五年左右的发展,Spring已经进化至5.x版本,在功能越来越强大的同时也变得越来越复杂,Spring Boot以习惯优于配置的理念对Spring做了封装简化,这样新用户就不需要硬磕十几年的技术沉淀,降低使用门槛高更容易上手。
-
微服务网关,负责将请求路由至后端的微服务,客户端不用关心后台具体由哪些微服务构成。另外,它还可以帮后端实现一些通用的横切面功能,例如:身份认证、操作鉴权、请求校验、安全检测、灰度发布、流量管控等。常见的开源产=品有: Netlix Zuul、Spring Cloud Gateway等。
-
服务注册中心,负责汇聚后端微服务的实例地址、状态等信息,以便微服务网关或消费方查询服务信息。有了它的协助,微服务就可以越拆越小,弹性伸缩也可以变得自动化。常见的开源产品有: Eureka、Nacos、Consul等。
-
统一配置中心,负责管理每个微服务在不同环境、集群中的动态配置, 配置 更新后可以实时地推送至对应微服务实例上,并及时生效。它可以简化大规模分布式系统配置的管理维护。常见的开源产品有: SpringCloud Config、Appollo等。
通常,每个微服务都存在身份认证、操作鉴权、请求校验、安全检测、灰度发布、流量管控等需求,这些属于横切面或通用功能,非常适合在微服务网关上实现,这样就不需要每个微服务重复实现上述功能了。像Nettlix Zuul、Spring Cloud Gateway等开源中间件,它们都支持过滤器Filter模式,我们可以基于此来扩展定制各种横切面或通用功能,让后端组件专注于业务,通过架构升级进一步细化分工 和加强合作。
在前后端分离的基础上,我们不断迭代、试错和演进,逐步找到了用户欢迎的业务形态,用户量开始不断增长。接着,我们就会进一步丰富业务,这时候后端组件也需要拆解成多个微服务组件了。为了支持后端多个微服务组件,我们就需要引进服务注册中心,支持服务的动态注册与发现。在统一配置中心、服务治理平台、调用链路追踪、日志监控等辅助系统协助之下,整个系统就演进至较完整的微服务架构了。至此,我们就可以实现服务治理、灰度发布等高级特性了。再往后我们就需要根据业务类型来决定是否引入分布式事务、分布式调度等解决方案了。
微服务倡导专业分工,每个组件都专注于各自的业务领域;微服务倡导精益创业,通过最小化可行产品(MVP)不断验证市场;微服务倡导敏捷迭代,通过灰度发布在线滚动升级系统。同样,我们在引|进微服务架构时也建议遵循上述原则,从实际需求出发,逐步演进至全套微服务架构,没有必要一次性采用全部套件。 为了降低采用新技术栈时的风险,我们可以从边缘系统开始微服务改造,等团队对新技术掌握的更好之后再开始改造核心系统。
综上所述,这种分离模式的方式有几个好处: