关于微服务和前后端分离。在讲微服务的时候，一直在强调两个核心点，大的单体要拆分成更小的一个个微服务模块，同时能够实现从it基础设施到数据库到后端逻辑层，再到前端页面展现层都纵向完完全全独立一套，而且各个微服务之间能够通过轻量的httpapi接口去做协同和集成。
但是如果没有前后端分离是否也存在微服务的说法。我们从所有关于微服务的概念介绍里面我们可以看到，从来没有任何一个点强调了必须要做前后端分离才是微服务。那为什么前后端分离，特别是最近这些年如此流行，这里面其实有两个关键点。第一是随着移动互联网开发，任何一个IT系统和应用开发出了有传统的桌面BS端，也会有手机APP端，同时肯能还会有IOS应用和安卓应用。所以，这个时候我们可以看到任何一个业务功能的实现，底层的业务功能服务可以是一套，但是前端往往是有多套，这个时候就会更加强调横向分层，包括前几年中台比较火的时候横向分层越来越收到重视，这也是大家前后端分离，并且逐渐衍生出Vue,React各种前端开发框架的原因。
我们为什么不是特别强调做微服务一定就要做前后端分离，举一个简单的例子，如果我们做的是传统企业内部信息化的业务系统，比如内部供应链系统，这个系统不存在移动端，也不存在与互联网打交道，这个时候前后端分离并非必须的，反而是招投标，框架协议，采购管理等模块前端需要做分离，前端不能融合成一块。在微服务应用里边，我们可以看到后台确实分离成多个微服务，但是前端反而又整合成一个微服务，所有功能前端都在一个大的开发包里面，这也不太符合我们说的微服务的拆分原则。因为当我们某一个业务功能出现变化的时候，会影响到其他业务模块。比如招投标发生变化，会影起整个前端微服务打包部署，会影响框架协议和采购管理模块。这是前后端分离的一个概念。
在实践前后端分离后，存在一个问题，究竟谁为前后端分离后业务功能负责。比如采购管理，采购订单制作到前后端分离后就麻烦了，因为后端开发只负责提供采购订单，采购执行逻辑相关的API接口，前端开发负责实际功能页面和接口组装执行。这个时候会发现一个关键问题，前端开发人员对业务逻辑并不熟悉，他只能讲一个个API基于前端功能调用对API进行组装，前端工作就完成了。但是这个时候功能是否完备，是否实现了所有业务场景和逻辑，前端开发人员实际上没有办法去做判断。典型的，这个时候应该是后端去完成这个事情。但是对于后端开发发现一个突出问题，当后端开发完所有接口交给前端，当前端完成所有前端功能以后，后端没有意识进入前端页面做黑盒测试。如果后端做的自测和单元测试不完备，就会造成前后端开发集成后，反而没有一个人对完整功能负责。所有功能到了最后测试的时候才发现，造成大量反攻和变更。这是前端后分离后引入导致的新的问题。
当然在前后端分离后，我们做好架构设计，提前制定好前后端分离中接口定义，后端开发人员开发完后可以做充足的单元测试，可以最大限度规避这些问题。但是实际项目开发过程中，这部分工作往往做得不够好。这并非是一个存粹技术问题，也设计研发管理过程中流程、规范、标准制定和执行的问题。
网友评论