为什么大公司一定要使用微服务？

这几年在 Java 工程师招聘时，会看到很多人的简历都写着使用了 Spring Cloud 做微服务实现，使用 Docker 做自动化部署，并且也会把这些做为自己的亮点。

图片来自 Pexels

而比较有趣的这其中以小公司出来的人为绝大多数，大的公司出来的人简历上倒是很少提这些东西。

对于我自己来说，从 2015 年就开始关注这一块，看过马丁·福勒最开始的关于微服务的论文、也看过不少对微服务的论证的英文文章和书，也研究过 Spring Cloud、Sofa 等开源实现以及 Service Mesh。

考虑到我们公司研发团队人力不足、基础设施不完善，当初是没有推行微服务的。

但随着看到上述的那种简历越来越多，有时候我也会疑问：难道真的不用微服务就落后了吗?公司的同事如果不掌握这些就真的没有竞争力了吗。

而随着最近公司业务的逐步提升，研发人员越来越多，借着在梳理公司的微服务落地计划时，也梳理了一下微服务的相关知识点，也是本文的主要内容。

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

微服务是什么

为什么要采用微服务

微服务架构

架构设计模式

服务拆分

微服务框架

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

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

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

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

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 以及去中心化实践。

其共同的架构原理：

单一职责

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

模块化和分而治之

特点：

用服务进行组件化

围绕业务能力进行组织

是产品而非项目

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

全自动化部署

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

面向失败设计

渐进式设计

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

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

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

为什么要采用微服务

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

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

生产力和复杂度的关系如图所示，可见系统越复杂，微服务带来的收益越大。此外，无论是单体应用还是微服务，团队的技能都需要能够把控住。

马丁·福勒的一个观点是：除非管理单体应用的成本已经太复杂了(太大导致很难修改和部署)，否则都不要考虑微服务。

大部分应用都应该选择单体架构，做好单体应用的模块化而不是拆分成服务。

因此，系统一开始采用单体架构，做好模块化，之后随着系统变得越来越复杂、模块/服务间的边界越来越清晰，再重构为微服务架构是一个合理的架构演化路径。

四个可以考虑上微服务的情况：

多人开发一个模块/项目，提交代码频繁出现大量冲突。

模块间严重耦合，互相依赖，每次变动需要牵扯多个团队，单次上线需求太多，风险大。

主要业务和次要业务耦合，横向扩展流程复杂。

熔断降级全靠 if-else。

微服务的三个阶段：

微服务 1.0：仅使用注册发现，基于 Spring Cloud 或者 Dubbo 进行开发。

微服务 2.0：使用了熔断、限流、降级等服务治理策略，并配备完整服务工具和平台。

微服务 3.0：Service Mesh 将服务治理作为通用组件，下沉到平台层实现，应用层仅仅关注业务逻辑，平台层可以根据业务监控自动调度和参数调整，实现 AIOps 和智能调度。

微服务架构

先决条件

微服务的先决条件如下：

快速的环境提供能力：依赖于云计算、容器技术，快速交付环境。

基本的监控能力：包括基础的技术监控和业务监控。

快速的应用部署能力：需要部署管道提供快速的部署能力。

Devops 文化：需要具有良好的持续交付能力，包括全链路追踪、快速环境提供和部署等，还需要快速的反应能力(对问题、故障的快速响应)，开发和运维的协同工作。

此外，根据康威定律和逆康威定律(技术架构倒逼组织架构改进)，组织架构也是一个很关键的因素。

对应于微服务架构，组织架构需要遵循以下原则：

一个微服务由一个团队维护，团队成员以三人为宜。

单个团队的任务和发展是独立的，不受其他因素影响。

团队是功能齐全、全栈、自治的，扁平、自我管理。

基础设施

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!