项目的架构

面试题：你的项目为什么要从单体变化到微服务？

为什么要从单体架构升级到微服务架构，单体架构和微服务架构的优缺点分别是什么？

单体服务的优点：

应用的开发很简单，IDE和其他开发工具只需要构建这一个单独的应用程序。

• 易于对应用程序进行大规模的更改:可以更改代码和数据库模式，然后构建和部署测试相对简。
• 直观:开发者只需要写几个端到端的测试,启动应用程序，调用RESTAPI，然后使用Selenium这样的工具测试用户界面。
• 部署简单明了:开发者唯一需要做的,就是把WAR文件复制到安装了Tomcat的服务器上。
• 横向扩展不费吹灰之力:运行多个实例，由一个负载均衡器进行调度。

单体服务的缺点

单体架构存在着巨大的局限性。随着业务的复杂和用户的增多，小巧的、简单的、由一个小团队开发维护的应用程序就会演变成一个由大团队开发的巨无霸单体应用程序。此时应用就变成了单体地狱。开发变得缓慢和痛苦。

• 过度的复杂性：大型单体应用程序的首要问题就是它的过度复杂性，系统本身过于庞大和复杂导致任何一个开发者都很难理解它的全部。因此，修复软件中的问题和正确地实现新功能就变得困难且耗时。各种交付截止时间都可能被错过。这种极度的复杂性正在形成一个恶性循环:由于代码库太难于理解，因此开发人员在更改时更容易出错，每一次更改都会让代码库变得更复杂、更难懂。就演变成为了我们常说的“代码屎山”。
• 开发速度缓慢：巨大的项目从编译到构建、运行再到测试这个周期花费的时间越来越长，这严重影响了团队的工作效率。
• 部署周期长，易出问题：代码开发人员多，提交代发多，代码库的构建结果长期处于无法交付状态；部署到线上也是要很长时间；代发库复杂，也容易引入未知问题；
• 难以扩展和可靠性不佳：项目太大，对服务器的要求也高，选着服务器时需要兼顾所有模块；且如果某一个模块出现问题（比如内存泄漏），可能导致整个应用崩溃。

单体应用的适用场景

 公司规模小，开发团队人数少，产品上线周期短，产品在快速迭代期，核心功能尚未稳定时；或者用户规模和用户群体较少时；

微服务架构 

微服务是模块化的，每个服务之间都是松耦合的，他们仅通过api进行通信，那么每个服务可以用自己自己的私有数据库；

微服务架构的好处：

• 使大型的复杂应用程序可以持续交付和持续部署。
• 每个服务都相对较小并容易维护。
• 服务可以独立部署。
• 服务可以独立扩展。
• 微服务架构可以实现团队的自主和松散耦合。
• 更容易实验和采纳新的技术。
• 更好的容错性，比如更好的故障隔离。

微服务架构的缺点：

• 服务的拆分和定义是一项挑战。
• 分布式系统带来的各种复杂性,使开发、测试和部署变得更困难。
• 当部署跨越多个服务的功能时需要谨慎地协调。

总结：

随着项目规模的变大，单体架构越来越复杂，开发发布周期变长；微服务架构可以独立部署，服务变小了，更容易维护，更容易独立扩展；故障之后也能更好的故障隔离；