为何大公司必定要使用微服务？

做者：飒然Hang
https://www.rowkey.me/blog/20...

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

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

对于我本身来讲，从 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 文化： 须要具备良好的持续交付能力，包括全链路追踪、快速环境提供和部署等，还须要快速的反应能力（对问题、故障的快速响应），开发和运维的协同工做。

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

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

• 一个微服务由一个团队维护，团队成员以三人为宜。
• 单个团队的任务和发展是独立的，不受其余因素影响。
• 团队是功能齐全、全栈、自治的，扁平、自我管理。

基础设施

微服务的推行须要依赖于不少底层基础设施，包括提供微服务的编译、集成、打包、部署、配置等工做，采用 PaaS 平台解决微服务从开发到运行的全生命周期管理，同时提供异构环境管理、容器资源隔离与互通、服务伸缩漂移、服务升级与回退、服务熔断与降级、服务注册与发现。

①最基本的基础设施

进程间通信机制： 微服务是独立进程的，须要肯定之间的通信方式。

服务发现+服务路由： 提供服务注册中心，服务提供者和消费者经过服务发现获取服务的信息从而调用服务，实现服务的负载均衡等。

服务容错： 微服务架构中，因为服务很是多，每每是一个服务挂了，整个请求链路的服务都受到影响。

所以须要服务容错，在服务调用失败的时候可以处理错误或者快速失败，包括熔断、Fallback、重试、流控和服务隔离等。

分布式事务支持： 随着业务拆分为服务，那么有时候不开避免的就是跨服务的事务，即分布式事务的问题。

原则是尽可能避免分布式事务，若是没法避免那么可使用消息系统或者 CQRS 和 Event Sourcing 方案来实现最终一致性。

若是须要强一致性，则有两阶段提交、三阶段提交、TCC 等分布式事务解决方案。

②提高外部服务对接效率和内部开发效率

API 网关： 负责外部系统的访问，跨横切面的公共层面的工做，包括安全、日志、权限控制、传输加密、请求转发、流量控制等。

典型的网关功能即对外暴露一个域名 xx.com，根据第一级目录作反向路由 xx.com/user，xx.com/trade。

每一级目录，如 user、trade 对应一个服务的域名。此外，API 网关也能够有服务编排的功能（不推荐）。

接口框架： 规范服务之间通信使用的数据格式、解析包、自解释文档，便于服务使用方快速上手等。

③提高测试和运维效率

配置中心: 运行时配置管理可以解决动态修改配置并批量生效的问题。包括配置版本管理、配置项管理、节点管理、配置同步等。

持续交付： 包括持续集成、自动化部署等流程。目的就是小步迭代，快速交付。

持续集成： 这一部分并不是是微服务特定的，对于以前的单体应用，此部分通常来讲也是必要的。

主要是指经过自动化手段，持续地对代码进程编译构建、自动化测试，以获得快速有效的质量反馈，从而保证代码的顺利交付。

自动化测试包括代码级别的单元测试、单个系统的集成测试、系统间的接口测试。

自动化部署： 微服务架构，节点数动辄上百上千，自动化部署可以提升部署速度和部署频率，从而保证持续交付。

包括版本管理、资源管理、部署操做、回滚操做等功能。而对于微服务的部署方式，包括蓝绿部署、滚动部署以及金丝雀部署。

④进一步提高运维效率

服务监控： 微服务架构下节点数目众多，须要监控的机器、网络、进程、接口等的数量大大增长，须要一个强大的监控系统，可以提供实时搜集信息进行分析以及实时分析之上的预警。

包括监控服务的请求次数、响应时间分布、最大/最小响应值、错误码分布等。

服务跟踪： 跟踪一个请求的完整路径，包括请求发起时间、响应时间、响应码、请求参数、返回结果等信息，也叫作全链路跟踪。

一般的服务能够和服务监控作在一块儿，宏观信息由服务跟踪呈现，微观单个服务/节点的信息由服务监控呈现。服务跟踪目前的实现理论基本都是 Google 的 Dapper 论文。

服务安全： 内网之间的微服务调用原则上讲应该是均可以互相访问写，通常并不须要权限控制，但有时候限于业务要求，会对接口、数据等方面有安全控制的要求。

此部分能够以配置的方式存在于服务注册中心中，和服务绑定，在请求时由作为服务提供者的服务节点进行安全策略控制。配置则能够存储在配置中心以方便动态修改。

在微服务数量不多的状况下，以上基础设施的优先级自上而降低低。不然，仅仅依赖人工操做，则投入产出比会很低。

还须要提到的是 Docker 容器技术。虽然这个对于微服务并非必须的，可是容器技术轻量级、灵活、与应用依存、屏蔽环境差别的特性对于持续交付的实现是相当重要的，即便对于传统的单体应用也可以给其带来交付效率的大幅提高。

 

架构设计模式

在引入微服务以后，传统的单体应用变为了一个一个服务，以前一个应用直接提供接口给客户端访问的架构再也不适用。

微服务架构下，针对不一样设备的接口作为 BFF 层（Backend For Frontend），也叫作用户体验适配层，负责聚合、编排微服务的数据转换成前端须要的数据。

服务之间的调用则在容许的状况下（容许延迟）尽量使用异步消息传递方式，如此造成面向用户体验的微服务架构设计模式。

以下图所示：

Client→API Gateway→BFF（Backend For Frontend）→Downstream Microservices：

• 后台采用微服务架构，微服务能够采用不一样的编程语言和不一样的存储机制。
• 前台采用 BFF 模式对不一样的用户体验（如桌面浏览器，Native App，平板响应式 Web）进行适配。
• BFF、API Orchestration Layer，Edge Service Layer，Device Wrapper Layer 是相同的概念。
• BFF 不能过多，过多会形成代码逻辑重复冗余。
• 能够将网关承担的功能，如 Geoip、限流、安全认证等跨横切面功能和 BFF 作在同一层，虽然增长了 BFF 层的复杂性，但可以获得性能优点。

服务拆分

微服务架构最核心的环节，主要是对服务的横向拆分。服务拆分就是将一个完整的业务系统解耦为服务，服务须要职责单一，之间没有耦合关系，可以独立开发和维护。

服务拆分不是一蹴而就的，须要在开发过程当中不断地理清边界。在彻底理清服务以前，尽可能推迟对服务的拆分，尤为是对数据库的拆分。

拆分方法以下：

• 基于业务逻辑拆分
• 基于可扩展拆分
• 基于可靠性拆分
• 基于性能拆分

其中，对于没法修改的遗留系统，采用绞杀者模式：在遗留系统外面增长新的功能作成微服务方式，而不是直接修改原有系统，逐步的实现对老系统替换。

拆分过程须要遵照的规范以下：

• 先少后多、先粗后细（粒度）
• 服务纵向拆分最多三层，两次调用：Controller、组合服务、基础服务
• 仅仅单向调用，禁止循环调用
• 串行调用改成并行调用或者异步化
• 接口应该幂等
• 接口数据定义严禁内嵌，透传
• 规范化工程名
• 先拆分服务，等服务粒度肯定后再拆分数据库。

微服务框架

上面讲述了微服务架构的众多基础设施，若是每个基础设施都须要本身开发的话是很是巨大的开发工做。目前市面上已经有很多开源的微服务框架能够选择。

Spring Boot

Spring Boot 是用来简化新 Spring 应用的初始搭建以及开发过程的。其虽然不是微服务框架，但其设计的初衷本质就是微应用的底层框架，所以很是适合用于微服务基础设施的开发以及微服务的应用开发。

尤为对于 Spring 技术栈的团队来讲，基于 Spring Boot 开发微服务框架和应用是天然而然的一个选择。关注微信公众号：Java技术栈，在后台回复：boot，能够获取我整理的 N 篇最新 Spring Boot 教程，都是干货。

Dubbo&Motan

Dubbo 是阿里开源的服务治理框架。其出如今微服务理念兴起以前，能够看作是 SOA 框架的集大成之做。

但其仅仅包含了微服务基础设施的部分功能，诸如熔断、服务跟踪、网关等都没有实现：

• 服务发现： 服务发布、订阅、通知。
• 高可用策略： 失败重试（Failover）、快速失败（Failfast）、资源隔离 - 负载均衡 ：最少活跃链接、一致性 Hash、随机请求、轮询等。
• 扩展性 ： 支持 SPI 扩展（service provider interface）。
• 其余 ： 调用统计、访问日志等。

Motan 则是微博开源的相似 Dubbo 的 RPC 框架，与 Dubbo 相比更轻量级。

Spring Cloud

Spring Cloud 是基于 Spring Boot 实现的微服务框架，也能够看作一套微服务实现规范。关注微信公众号：Java技术栈，在后台回复：cloud，能够获取我整理的 N 篇最新 Spring Cloud 教程，都是干货。

基本涵盖了微服务基础设施的方方面面，包括配置管理、服务发现、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式会话和集群状态管理等。

其基于 Spring 生态，社区支持很是好。但其不少组件都没有通过生产环境验证，须要慎重选择。

Spring Cloud Netflix 是 Spring Cloud 的一个子项目，是 Spring 对 Netflix OSS 的集成实现。

基于 Netflix 的大规模使用，其中的已经被普遍使用的组件包括：

• Eureka： 服务注册和服务发现
• Ribbon： 弹性而智能的进程间和服务通信机制，客户端负载均衡
• Hystrix： 熔断器，在运行时提供延迟和容错的隔离
• Zuul： 服务网关

此外，另外一个子项目 Spring Cloud Alibaba 则是 Alibaba 开源的基于 Spring Boot 的微服务框架，主要是对阿里云服务的支持。

Service Mesh

上述的微服务框架都是侵入式的，服务化的过程都须要进行代码改造。Service Mesh 则是下一代微服务架构，最明显的特征就是无入侵。采用 Sidecar 模式来解决系统架构微服务化后的服务间通讯和治理问题。

以下图所示：

目前主流的开源实现包括：

• Linkerd 和 Envoy： 以 Sidecar 为核心，关注如何作好 Proxy，并完成一些通用控制平面的功能。缺少对这些 Sidecar 的管理和控制。
• Istio 和 Conduit： 目前最为流行的 Service Mesh 实现方案，集中在更增强大的控制平面(Sidecar 被称为数据平面)功能。

  前者由 Google 和 IBM 合做，并使用了 Envoy 做为 Sidecar 部分的实现；后者则是 Linkerd 做者的做品。

  相比起来，Istio 有巨头背景，功能强大，但可用性和易用性一直不高，Conduit 则相对简单、功能聚焦。

限于 Service Mesh 带来的性能延迟的开销以及 Sidecar 对分布复杂性的增长，其对大规模部署(微服务数目多)、异构复杂(交互协议/开发语言类型多)的微服务架构带来的收益会更大。

Sofastack

蚂蚁金服开源的构建金融级分布式架构的一套中间件。包括微服务开发框架、RPC 框架、服务注册中心、全链路追踪、服务监控、Service Mesh 等一整套分布式应用开发工具。

特别值得一提的是 SOFAMesh。其实对下一代微服务架构 Service Mesh 的大规模落地方案实践，基于 Istio 改进和扩展而来，应该是国内最为成熟的开源 Service Mesh 方案。

此外，须要提到 Kubernetes（K8s），其自己提供了部分的微服务特性支持（经过域名作服务发现），对代码无侵入。但服务调用、熔断这些都须要本身实现。

综上，目前公司技术团队技术栈是 Spring，而且已有服务的实现都是基于 Dubbo。

所以选择 Spring Cloud Netflix 作为基础的微服务框架，对其中不成熟或者缺少的组件，选择业界更为成熟的组件替代便可：

• API 网关： Zuul。
• 服务注册中心： Dubbo。
• 配置中心： Disconf。
• 服务监控&全链路追踪： CAT。
• 服务开发框架： Spring Boot。
• 日志监控、告警： ELK+Elasalert。
• 流量控制： Sentinel。
• 消息队列： Kafka。

推荐去个人博客阅读更多：

1.Java JVM、集合、多线程、新特性系列教程

2.Spring MVC、Spring Boot、Spring Cloud 系列教程

3.Maven、Git、Eclipse、Intellij IDEA 系列工具教程

4.Java、后端、架构、阿里巴巴等大厂最新面试题

生活很美好，明天见～