1.可以实现真正的前后端解耦，前端服务器使用nginx。
前端/WEB服务器放的是css，js，图片等等一系列静态资源（甚至你还可以css，js，图片等资源放到特定的文件服务器，例如阿里云的oss，并使用cdn加速），前端服务器负责控制页面引用\u0026跳转\u0026路由，前端页面异步调用后端的接口，后端/应用服务器使用tomcat（把tomcat想象成一个数据提供者），加快整体响应速度。
（这里需要使用一些前端工程化的框架比如nodejs，react，router，react，redux，webpack）
2.发现bug，可以快速定位是谁的问题，不会出现互相踢皮球的现象。
页面逻辑，跳转错误，浏览器兼容性问题，脚本错误，页面样式等问题，全部由前端工程师来负责。
接口数据出错，数据没有提交成功，应答超时等问题，全部由后端工程师来解决。
双方互不干扰，前端与后端是相亲相爱的一家人。
3.在大并发情况下，我可以同时水平扩展前后端服务器，比如淘宝的一个首页就需要2000+台前端服务器做集群来抗住日均多少亿+的日均pv。
（去参加阿里的技术峰会，听他们说他们的web容器都是自己写的，就算他单实例抗10万http并发，2000台是2亿http并发，并且他们还可以根据预知洪峰来无限拓展，很恐怖，就一个首页。。。）
4.减少后端服务器的并发/负载压力
除了接口以外的其他所有http请求全部转移到前端nginx上，接口的请求调用tomcat，参考nginx反向代理tomcat。
且除了第一次页面请求外，浏览器会大量调用本地缓存。
5.即使后端服务暂时超时或者宕机了，前端页面也会正常访问，只不过数据刷不出来而已。
6.也许你也需要有微信相关的轻应用，那样你的接口完全可以共用，如果也有app相关的服务，
那么只要通过一些代码重构，也可以大量复用接口，提升效率。（多端应用）
7.页面显示的东西再多也不怕，因为是异步加载。
8.nginx支持页面热部署，不用重启服务器，前端升级更无缝。
9.增加代码的维护性\u0026易读性（前后端耦在一起的代码读起来相当费劲）。
10.提升开发效率，因为可以前后端并行开发，而不是像以前的强依赖。
11.在nginx中部署证书，外网使用https访问，并且只开放443和80端口，其他端口一律关闭（防止黑客端口扫描），
内网使用http，性能和安全都有保障。
12.前端大量的组件代码得以复用，组件化，提升开发效率，抽出来！
1.便于单个服务的扩容。哪一个服务在运行过程中发现使用频率高、压力大，那么就可以创建这个api的多个实例，横向扩展来实现扩容减压削峰。
2.便于程序代码更新维护。多人协作开发，每个人负责的服务都不一样。为了发布某个服务时不影响其他线上正常运行的服务，一般每个服务都有自己的git库，开发、部署都是独立的，因为一个大系统被拆分成n个小服务，所以开发维护起来也方便。
3.符合微服务各司其职，服务间低耦合高内聚的理念。微服务，服务间就是要保持高度的无关性、单一性，服务不建议跨职责。那么api分离以后使得项目结构更清晰，调用链路更明了，出问题后跟着链路排查更方便快速。
4.代码复用。一个小的微服务项目中，可能有common、spi、provider、consumer、cache、mq这几个公用模块，他们是为api提供服务的，那么如果以后想加其他的api模块（比如back是给后台管理系统的前端接口使用的），那么就可以直接依赖spi或者provider，他们就会互相引用依赖，来实现面向前端接口的api模块共用一套基础模块系列。
现在的软件开发模式和传统的有很多差别，传统的开发模式耦合度较高，随着技术的发展越来越多的开发模式被应用，比如微服务架构模式。其实很多开发语言都有自己的微服务解决方案，如Java系的Spring Boot、Spring Cloud等。但在实际项目开发中，即使是在微服务开发模式下，依旧有很多人喜欢单独抽离出一个api模块，这是为什么呢？
什么是微服务？
其实“微服务”并不是一种新的技术，而是一种新兴的架构模式。简单的说就是将一个服务拆成多个颗粒度小、易复用的子服务，这样做的好处就是：
应用/服务解耦，避免了单个业务过于复杂；
每个微服务独立开发和部署，扩展性更强，可以实现服务高可用；
服务组件化，易复用。
后端微服务开发时为什么还要单独抽离API模块？
既然我们是以微服务模式来开发项目的，为什么很多开发者还习惯性的建立一个API模块出来呢？
其实开发微服务时，可以采用单模块模式来开发，而很多人采用多模块来开发是因为遵循了“高内聚、低耦合”的设计模式，这样做的优点就是：
1、边界清晰、易于管理
一个中型项目在开发时会有很多业务和模块，它们分散在各个包中，这样就很混乱。如果有些API是希望对外公开的，有些API只允许内部访问或有限访问，那就有必要将公开的API单独抽离到一个单独的API模块中，这样管理起来更方便。
2、各模块间更容易聚合
把项目拆成多模块来开发，我们可以通过maven等来解决依懒关系，可以很方便的实现模块间的聚合，各个模块也可以单独使用。
比如将工程拆分为这几个模块：公共模块、对外API模块、管理和监控模块、业务模块等。
以上就是我的观点，对于这个问题大家是怎么看待的呢？欢迎在下方评论区交流 ~ 我是科技领域创作者，十年互联网从业经验，欢迎关注我了解更多科技知识！
API是一个比较特殊的层，前面对接客户端，后面对接微服务，一般来说，API承担网关的角色，需要暴露在公网，最好部署在DMZ区域（可以理解为特殊隔离区），功能上除了处理业务请求外，还要承担鉴权，限流，熔断，服务降级等全局任务，所以一般会单独拎出来，作为一个独立模块开发和运维
不单单java提倡后端api单独模块拿出来调用，现在编程语言同样都提倡如此。
那么，我们为什么要这样做呢？有什么好处吗？
首先，我们说说目前对于web应用有哪些使用场景。一般而言，一个web应用，必定有个后台管理，其次可能会有门户网站，或者小程序，或者h5，再或者安卓和iOS。这么多端，这多的对接，如果我们每套都做对应接口那后端人不烦死了？
所以我们会想着方便，统一用一套标准，这个就是所谓的前后端分离。
这样下来我们后端开发就可以省很多时间。可以做更多其他事情。
前后端分离可以起到程序不必过于依赖某一块代码，咋们写的程序看起来也不会太过冗余。评判一个代码写的好坏，我们会从代码的简洁，可复用的程度，变量命名是否言简意赅等。
所以努力做个优秀开发者，不要只做码农，好好创造，你是最优秀的程序员哟。
觉得我说的还马马虎虎的，给个关注。
首先微服务本就是由一个个的服务组成，每个服务基本都是以API的形式对外/内提供服务的
拆分的粒度
根据公司规模，pv，uv的不通，拆分的多少也不同，
例如:有几块业务，每天uv也就那么几个几十个，pv几千不过万，并且可预见的未来也不会上涨，那就没必要每个业务一个微服务，完全可以合并成一个;
再比如:有一个接口，并发量过千上万，那么，这一个接口就可以独立出来一个服务
按业务划分
对内api服务，对外api服务，业务a服务，业务b服务，等等，当然这些服务结合实际情况也可以合并成一个，直到达到某种条件之后，再分离出来.
另外某一块业务，长期内需要经常性的变动发版，为了不影响其它功能，也可以独立出一个服务，待到时机成熟后，再合并到其它服务中
总结
微服务并不是说越多越好，需要结合公司内部情况，量力而行，关于业务划分亦是如此。因此。api模块单独分离出来对公司对业务的好处在那里？这是一个需要深思的问题。并不是说大佬公司分离了，我们也要分离