微服务起源

单体架构

这个架构非常简单，曾经的SSH(struts+spring+hibernate)框架以及后来的SSM（Spring + Spring MVC + MyBatis ）框架配合JSP技术渲染前端页面都是单体架构最好的实践途径。通常将所有功能打包成一个war或者jar包，部署在tomcat等中间件即可。

日积月累这个应用会慢慢变成庞大而复杂的怪物，项目启动时间、数据备份大小不断增加。随着项目人员的更替，时间一长很难有人完全搞懂代码之间的逻辑关系。部分研发工程师可能担心修改遗留代码出现不可知的缺陷，宁愿增加大量不必要代码，导致应用越来越庞大，越来越复杂，可读性越来越差，最终陷入恶性循环。

单体应用扩展能力差，高可用能力不强，资源利用率不高，容易造成资源浪费。开发测试周期耗时较长，交付质量和周期难以保障，很难实现快速交付，对业务响应能力相对较慢。

微服务架构

应对以上情况，微服务架构应运而生，微服务提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通。每个服务都围绕着具体业务进行构建，并且能够独立的部署到生产环境、类生产环境中。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

优点

降低复杂度快速迭代

服务细粒度拆分，一个服务只关注一个特定的业务领域，并提供清晰的接口表述服务边界。服务体积小、复杂度低、开发运维都会更容易。

扩展性强

每个服务独立部署，服务体积小，发布更高效，可根据每个服务业务需求来灵活扩展。

容错性

挑战

故障排查

每个请求可能会经历多个服务交互，交互链路较长，每个微服务独立日志，出现故障，定位根源会比较困难。

服务监控

微服务建构中，监控的开销非常大，不仅要对整个链路监控、整合日志，还要对每个微服务类似单体系统的监控。

系统复杂度

服务间相互依赖远程通信，网络延迟和故障不可避免，服务数量增加，各个服务间存在更多依赖关系，业务复杂度陡增。

何时采用微服务架构

微服务并不适合所有的场景，因为一旦拆开，通信成本就会上升，架构复杂度会上升，开发人员需要更多，集成测试、部署都会变得更复杂，所以技术选型一定要慎重。

产品初期优先选择单体架构。面对一个新的领域，业务复杂度不高，业务认知高度很难清晰，往往需要时间加深对业务的认知。业务、资源受限的情况，单体架构可以快速落地，微服务架构反而成为了障碍，风险巨大。当业务复杂度达到一定程度时，微服务的优势才会显现出来，从现有单体架构逐步拆分服务，服务的划分应该逐步进行，持续演进。几乎所有成功的微服务架构都是从一个巨大的单体架构拆分而来的。

先决条件

微服务架构启动前，应保障基础设施、公共服务先决条件准备完毕。

自动化工具链

服务的增加，手动打包部署交付出错的风险明显提升。

完善的监控系统

微服务框架

快速资源申请

流程规范

 关注公众号，发送 ms 免费获取 海量JAVA大厂面试题。