最后
== 就答题情况而言，第一问100%都可以回答正确，第二问大概只有50%正确率，第三问能回答正确的就不多了，第四问再正确就非常非常少了。其实此题并没有太多刁钻匪夷所思的用法，都是一些可能会遇到的场景，而大多数人但凡有1年到2年的工作经验都应该完全正确才对。 只能说有一些人太急躁太轻视了，希望大家通过此文了解js一些特性。
并祝愿大家在新的一年找工作面试中胆大心细，发挥出最好的水平，找到一份理想的工作。 开源分享：docs.qq.com/doc/DSmRnRG…
1、单体架构有很多好处：
开发效率高：模块之间交互采用本地方法调用，并节省微服务之间的交互讨论时间与开发成本。
容易测试：IDE都是为开发单个应用设计的、容易测试——在本地就可以启动完整的系统。
容易部署：运维成本小，直接打包为一个完整的包，拷贝到web容器的某个目录下即可运行。但是，上述的好处是有条件的，它适用于小型简单应用，对于大规模的复杂应用，就会展现出来以下的不足：
1、复杂性逐渐变高，可维护性逐渐变差 ：所有业务模块部署在一起，复杂度越来越高，修改时牵一发动全身。
2、版本迭代速度逐渐变慢：修改一个地方就要将整个应用全部编译、部署、启动时间过长、回归测试周期过长。
3、阻碍技术创新：若更新技术框架，除非你愿意将系统全部重写，无法实现部分技术更新。
4、无法按需伸缩：通过冗余部署完整应用的方式来实现水平扩展，无法针对某业务按需伸缩。
许多大型公司，通过采用微服务架构解决了上述问题。其思路不是开发一个巨大的单体式的应用，而是将应用分解为小的、互相连接的微服务。
一个微服务一般完成某个特定的功能，比如订单服务、用户服务等等。每一个微服务都是完整应用，都有自己的业务逻辑和数据库。一些微服务还会发布API给其它微服务和应用客户端使用。
比如，根据前面描述系统可能的分解如下：
每一个业务模块都使用独立的服务完成，这种微服务架构模式也影响了应用和数据库之间的关系，不像传统多个业务模块共享一个数据库，微服务架构每个服务都有自己的数据库。
微服务架构的好处：
-
分而治之，职责单一；易于开发、理解和维护、方便团队的拆分和管理
-
可伸缩；能够单独的对指定的服务进行伸缩
-
局部容易修改，容易替换，容易部署，有利于持续集成和快速迭代
-
不会受限于任何技术栈
[
学习分享，共勉
题外话，毕竟我工作多年，深知技术改革和创新的方向，Flutter作为跨平台开发技术、Flutter以其美观、快速、高效、开放等优势迅速俘获人心
开源分享：【大厂前端面试题解析+核心总结学习笔记+真实项目实战+最新讲解视频】
