后台面试-微服务架构常见问题

微服务架构

背景

传统的WEB应用核心分为业务逻辑、适配器以及API或通过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。

通常我们把所有的模块写在同一个程序中单体打包，部署在服务器，比如对于 java 应用来说，可以打包成 jar 或者 war ，部署在 Tomcat 容器中。 这种传统方式适合于小型业务，开发快、代码集中、易于 Debug 、部署方便、不同模块间没有网络损耗。

但对于现在大型互联网公司来说，这种传统方式已经无法适用了：

• 开发效率低：大量的开发都集中在同一个代码仓库中，提交、同步代码时需要频繁的进行代码合并；
• 代码维护难：代码功能耦合在一起，新人难以维护老代码；
• 部署不灵活：一个小改动就需要将整个系统的代码重新编译部署；
• 稳定性存疑：某一个模块出了 bug ，整个系统都可能会死掉（比如 C++ 发生段错误，整个进程会被杀掉；
• 拓展性不够：如果业务量超过了单机负载能力，除了提升服务器性能没有很好的方法。

基本模式

微服务运用了以业务功能的设计概念，应用程序在设计时就能先以业务功能或流程设计先行分割，将各个业务功能都独立实现成一个能自主运行的个体服务，然后再利用相同的协议