微服务，为何从先后端分离开始？

既要低头赶路，又要抬头望天，科技是为人服务的，任何技术背后都有更深层次的考量，在本系列的第一篇文章中咱们聊了微服务的本质，它是一种能够加速分工、促进合做的新协做机制。知其然，知其因此然，在第二篇文章中咱们剖析了微服务为何能够加速分工、促进合做，今天咱们再接着来聊聊怎样开启微服务架构之旅。

• 微服务到底改变了什么，你知道吗？
• 微服务，为何能够加速分工、促进合做？

1. 从先后端分离开启微服务改造

如今咱们对微服务有了更深刻的了解，也准备在构建新系统时采用这套新架构了，但它仍是有些复杂度的，包括服务注册中心、统一配置中心、微服务网关、接入层网关、服务治理中心、调用链路追踪、分布式事务和分布式调度等众多组件。一口吃成胖子仅仅是一个美好的愿望，从单体式架构直接升级至全微服务架构，须要掌握这套全新的技术栈，对于缺少前期铺垫的团队来讲，学习曲线仍是比较陡的，真正遇到的挑战每每超出想象的。

心理学对此有专门的研究，咱们探索陌生世界的动力源于兴趣，而兴趣就是好奇心和正向反馈。若是咱们刚开始就把目标设定的过高太远，在坚持努力了一段时间以后，还没法达成目标的话，那咱们就接收不到正向反馈。长此以往，好奇心就会消磨殆尽，兴趣也就随之消失了。最靠谱的方式就是段带式进阶，将一个很是宏大的目标拆解成多个阶段性目标。在当前能力水平下，最近的阶段性目标只须要咱们稍做努力跳跳脚就能够完成的，这样咱们就能持续地收获小糖豆，从而激发更大好奇心和更强的战斗力，一步一台阶地顺利抵达最初设定的大目标。

所以，我推荐从难度较小的先后端分离来启动微服务化改造。那为何先后端分离适合做为切入点呢？这源于对大量用户案例的分析和总结，接下来咱们一块儿看看这当中蕴含的逻辑。一般，咱们能够按照下面三种规则将单体式拆解成微服务：

• 按业务类型分，每一个组件负责不一样的业务，彼此之间松耦合。
• 按技术类型分，某些特性只能采用特定的语言或框架来实现。
• 按地域边界分，研发团队分布在不一样地方，受沟通成本限制。

按照上述规则看，先后端是否适合拆成两个组件呢？从总体感受看，前端就像要接待客户的岗位，必须把本身收拾的干干净净，给客户留下好印象，然后端就像后援岗位的程序员，平常主要跟机器打交道，怎么舒服怎么穿。从功能定位看，前端担负人机交互，关注业务流程，后端负责算法数据，关注运算逻辑。从质量属性看，前端看重易用性、美观度等，后端看重扩展性、可用性和性能等。从资源需求看，前端主要消耗内存和带宽，后端主要消耗CPU。从迭代频次看，前端须要不断试错，变化要远高于后端。从技能要求看，前端主攻HTML/CSS/JS等，研究怎样跟人交互更高效顺畅，后端主攻高级编程语言等，研究怎样跟机器打交道更高效稳定。

按上述分析看，先后端是很是适合拆开的。在云计算时代到来以前，即移动互联网时代，为了跨终端，先后端分离就已经开始流行了，应该说有比较成熟的用户基础了。同时，从先后端分离架构的逻辑、过程等视图看，这套方案相对简单，容易上手，很是适合做为微服务化改造的第一步。在此方案中，咱们只须要引入接入层网关和开发框架（SpringBoot），前者用于承载前端组件，后者下降开发难度。接入层网关,一般以Nginx、OpenRestry、Kong等开源中间件为基础扩展，支持从服务治理平台接收控制指令，实现前端热发布和页面级灰度。另外，利用中间件自己的插件机制来实现业务需求定制。

• 前端组件能够采用React、Vue等框架开发，发布时将HTML/CSS/JS等静态资源打成ZIP包。
• 后端组件将服务封装成HTTP RESTful API，发布时打成特定的压缩包，例如：FatJAR、WAR等。
• 前端以AJAX方式调用后端服务，报文采用JSON格式编码。
• 接入层网关会对客户端（浏览器）的请求作路由转发，静态资源请求在本地处理，动态服务请求转给后端。

2. 分步骤演进至全微服务架构

俗话说万事开头难，将先后端分离做为切入点，咱们能够轻松地开启微服务化改造之旅。接下来，咱们如何一步步趋近至全微服务架构呢？以JAVA领域为例，以下图所示，典型的微服务架构主要包含下列组件：

• 接入层网关，负责将流量落地并对其进行安全检测，而后分流静态和动态请求。另外，前端组件的静态资源会部署在它里面。常见的开源产品有：Nginx、OpenRestry、Kong等。
• 应用开发框架，用于搭建应用的骨架，例如：Spring Boot。历经十五年左右的发展，Spring已经进化至5.x版本，在功能愈来愈强大的同时也变得愈来愈复杂，Spring Boot以“习惯优于配置”的理念对Spring作了封装简化，这样新用户就不须要硬磕十几年的技术沉淀，下降使用门槛高更容易上手。
• 微服务网关，负责将请求路由至后端的微服务，客户端不用关心后台具体由哪些微服务构成。另外，它还能够帮后端实现一些通用的横切面功能，例如：身份认证、操做鉴权、请求校验、安全检测、灰度发布、流量管控等。常见的开源产品有：Netflix Zuul、Spring Cloud Gateway等。
• 服务注册中心，负责汇聚后端微服务的实例地址、状态等信息，以便微服务网关或消费方查询服务信息。有了它的协助，微服务就能够越拆越小，弹性伸缩也能够变得自动化。常见的开源产品有：Eureka、Nacos、Consul等。
• 统一配置中心，负责管理每一个微服务在不一样环境、集群中的动态配置，配置更新后能够实时地推送至对应微服务实例上，并及时生效。它能够简化大规模分布式系统配置的管理维护。常见的开源产品有：Spring Cloud Config、Appollo等。

一般，每一个微服务都存在身份认证、操做鉴权、请求校验、安全检测、灰度发布、流量管控等需求，这些属于横切面或通用功能，很是适合在微服务网关上实现，这样就不须要每一个微服务重复实现上述功能了。像Netflix Zuul、Spring Cloud Gateway等开源中间件，它们都支持过滤器Filter模式，咱们能够基于此来扩展定制各类横切面或通用功能，让后端组件专一于业务，经过架构升级进一步细化分工和增强合做。

在先后端分离的基础上，咱们不断迭代、试错和演进，逐步找到了用户欢迎的业务形态，用户量开始不断增加。接着，咱们就会进一步丰富业务，这时候后端组件也须要拆解成多个微服务组件了。为了支持后端多个微服务组件，咱们就须要引进服务注册中心，支持服务的动态注册与发现。在统一配置中心、服务治理平台、调用链路追踪、日志监控等辅助系统协助之下，整个系统就演进至较完整的微服务架构了。至此，咱们就能够实现服务治理、灰度发布等高级特性了。再日后咱们就须要根据业务类型来决定是否引入分布式事务、分布式调度等解决方案了。

微服务倡导专业分工，每一个组件都专一于各自的业务领域；微服务倡导精益创业，经过最小化可行产品（MVP）不断验证市场；微服务倡导敏捷迭代，经过灰度发布在线滚动升级系统。一样，咱们在引进微服务架构时也建议遵循上述原则，从实际需求出发，逐步演进至全套微服务架构，没有必要一次性采用所有套件。为了下降采用新技术栈时的风险，咱们能够从边缘系统开始微服务改造，等团队对新技术掌握的更好以后再开始改造核心系统。

坚持原创不易，若是你以为有价值，麻烦动动手指点下文 「 推荐 」按钮，让更多小伙伴能够看到，老兵哥会更有动力坚持分享的。另外，我后续还会分享职业规划、应聘面试、技能提高、影响力打造等经验，欢迎 关注 本专栏或微信公众号 「 IT老兵哥 」！

关注「 IT老兵哥 」，赋能程序人生！近期热评文章《 架构师入门系列 》：

• 架构究竟是什么，你知道吗？ （阅读人数：1110）
• 架构都有哪些，我该怎么选？ （阅读人数：847）
• 架构师都干什么，你知道吗？ （阅读人数：1127）
• 练就哪些技能才胜任架构师？ （阅读人数：1096）
• 怎样才能搞定上下游的客户？ （阅读人数：466）
• 如何从开发岗转型作架构师？ （阅读人数：1204）
• 程序员必须懂的架构入门课    （阅读人数：557）