为什么大公司Java后端要使用微服务？

主要从以下几个方面跟大家分享：

• 微服务是什么

• 为什么要采用微服务

• 微服务架构

• 架构设计模式

• 服务拆分

• 微服务框架

开篇之前先声明我对微服务的几点态度：

• 架构模式有很多，微服务不是唯一的选择也不是什么银弹。国内绝大多数中小公司引入微服务都是在盲目追新，也能看出做此种技术选型的工程师基础架构素质的不足。

• “你必须长的足够高才能使用微服务”。微服务基础设施，尤其是容器技术、自动化部署、自动化测试这些不完备，微服务形同虚设，不会带来什么质的提升。

• 微服务架构的关键不在于具体的实现，而在于如何合理地划分服务边界以及组织架构是否相匹配。不考虑研发团队的规模和组成就盲目上微服务是不良的技术选型。

• Spring Boot 是 Spring 全家桶的上层封装，并不是什么崭新的技术，也不是什么值得成为自己杀手锏的技术。

• Spring Cloud 中 Spring Cloud Netflix 的组件是经过生产环境验证的，其他的则建议慎重选择。

微服务是什么

微服务起源于 2005 年 Peter Rodgers 博士在云端运算博览会提出的微 Web 服务(Micro-Web-Service)，根本思想类似于 Unix 的管道设计理念。

2014 年，由 Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务架构风格是一种通过一套小型服务来开发单个应用的方法，每个服务运行在自己的进程中，并通过轻量级的机制进行通讯（HTTP API）。

关键的三点是：

• small

• automated

• lightweight

对比 SOA，微服务可以看做是 SOA 的子集，是轻量级的 SOA，粒度更细的服务，独立进程、数据分离，更注重敏捷、持续交付、DevOps 以及去中心化实践。

其共同的架构原理：

• 单一职责

• 关注分离：控制与逻辑相分离

• 模块化和分而治之

特点：

• 用服务进行组件化

• 围绕业务能力进行组织

• 是产品而非项目

• 端点智能化和哑管道: 控制逻辑都在端点，管道仅仅是传输

• 全自动化部署

• 语言和数据的去中心化控制

• 面向失败设计

• 渐进式设计

综合来看，其优缺点如下：

• 优点： 模块的强边界；独立部署；技术选型的多样性。

• 缺点： 分布式带来编程复杂度，远程调用的消耗；舍弃强一致性，实现最终一致性；操作复杂性要求有一个成熟的运维团队或者运维基础设施。

为什么要采用微服务

是否选择微服务取决于你要设计的系统的复杂度。微服务是用来把控复杂系统的，但是随之而来的就是引入了微服务本身的复杂度。

需要解决包括自动化部署、监控、容错处理、最终一致性等其他分布式系统面临的问题。即使已经有一些普遍使用的解决方案，但是仍然是有不小的成本的。

 

生产力和复杂度的关系如图所示࿰