转载

微服务架构深度解析与最佳实践-第二部分：四个特点和六个能力、常见框架

微服务架构的特点、优势和常见技术

微服务的四个特点和六个能力

现在让我们分析一下上一节里的各个技术大牛们阐述的技术观点，从设计开发、系统部署、测试运维和服务治理四个主要方面来考虑微服务架构的特点，那么这四个方面就可以总结为下图：

微服务架构首先是一个分布式的架构，其次我们要暴露和提供业务服务能力，然后我们需要考虑围绕这些业务能力的各种非功能性的能力。这些分散在各处的服务本身需要被管理起来，并且对服务的调用方透明，这样就有了服务的注册发现的功能需求。

同样地，每个服务可能部署了多台机器多个实例，所以，我们需要有路由和寻址的能力，做负载均衡，提升系统的扩展能力。有了这么多对外提供的不同服务接口，我们一样需要有一种机制对他们进行统一的接入控制，并把一些非业务的策略做到这个接入层，比如权限相关的，这就是服务网关。同时我们发现随着业务的发展和一些特定的运营活动，比如秒杀大促，流量会出现十倍以上的激增，这时候我们就需要考虑系统容量，服务间的强弱依赖关系，做服务降级、熔断，系统过载保护等措施。

以上这些由于微服务带来的复杂性，导致了应用配置、业务配置，都被散落到各处，所以分布式配置中心的需求也出现了。最后，系统分散部署以后，所有的调用都跨了进程，我们还需要有能在线上做链路跟踪，性能监控的一套技术，来协助我们时刻了解系统内部的状态和指标，让我们能够随时对系统进行分析和干预。这六种能力总结如下图：

微服务架构深度解析与最佳实践-第二部分：四个特点和六个能力、常见框架

微服务的优势

为什么我们要从单体系统走向微服务架构呢？我们先来看一个图。

微服务架构深度解析与最佳实践-第二部分：四个特点和六个能力、常见框架

这个图 x 轴是系统复杂度，y 轴是开发的生产力，我们可以看到：

在系统复杂度很低的时候，单体的生产力要高一点，这是因为拆分微服务，管理这些服务的成本增加了
当复杂度开始增加，单体的生产力快速的降低，而微服务则不太受影响，这是因为复杂度大了，单体牵一发而动全身，各种耦合和相互影响太多
随着复杂度越来越高，微服务的低耦合开始减低了生产力的衰变，而单体架构的生产力则会降到一个非常低的水平

也就是说微服务应用在复杂度低的情况下，生产力反而比单体系统低。在复杂度高的地方，情况恰恰相反。

随着复杂度升高，单体架构的生产力快速下降，而微服务相对平稳，所以，复杂度越高的业务系统，越适合使用微服务架构。

搞清楚了微服务架构与单体架构的生产力的区别以后，我们再来看看微服务有哪些优势，我总结了一下有以下几点：

服务简单：因为微小，所以简单，从一个大泥球，变成了很多个小而美的颗粒，每个小颗粒职责单一，边界明确，可以通过简单组装完成大的功能，自然就比之前的大泥球好处理得多。
灵活扩展：单体的情况下，只能通过增加机器，再部署多套单体系统做成集群，前面加负载均衡来扩展；微服务以后，我们会发现用户服务压力不大不用扩展，订单服务压力大的时候多部署两台就可以了，这样我们就把扩展的方式从全部优化到局部。
便于维护：如果一个系统有 100 个业务功能，依赖关系相互耦合到一起，那么这就是维护的恶梦，这样的系统没有任何免疫力，修改任何一个功能，都可能会导致整个系统崩溃。微服务就简单得多了，每个服务自己出现问题，其他服务不会直接受到影响。同时维护具体某个服务的人员，也不需要一上来就学习全部的业务知识，比如用户服务模块的维护人员，只需要先学习用户服务的业务就可以上手工作了。
独立演进：变成微服务以后，各个独立系统的内部设计和实现细节都被隔离开，相互之间不受影响，只要服务间的接口不变，大家就可以各自独立的发展自己的系统，完成升级、重构、功能增强等等。
混合开发：各服务独立开发的另外一个好处就是，各个独立系统可以使用自己的技术栈和研发模式，包括开发语言和工具、数据库存储和中间件等技术，这样有助于试验和引入更先进和创新的技术，从一些个边缘服务开始尝试，技术、工具、中间件、研发模式，孵化成熟以后，可以大范围推广，实现技术和研发能力的持续更新换代，让研发组织保持长期的优势和活力，充分获得技术发展的红利。
持续交付：微服务比单体系统简单明确，这样就便于我们利用自动化测试和自动化部署来加速功能的迭代，配合 CI/CD 等基础设施，实现业务功能的持续交付，保障研发能够紧跟业务发展变化的节奏。

常见的微服务技术框架

具体怎么做微服务呢？我们先看看大家最常简单见到的微服务的图：

微服务架构深度解析与最佳实践-第二部分：四个特点和六个能力、常见框架

在互联网出行业务中，用户通过 API 网关访问系统的乘客、司机、出行三个 REST 服务，这三个服务再通过 REST 访问计费、支付和通知三个服务。看起来很简单，也好理解，但是实际的业务系统里，设计和实现一般会是这样：

微服务架构深度解析与最佳实践-第二部分：四个特点和六个能力、常见框架

服务框架：我们可以选择用 Spring Cloud 或者 Apache Dubbo，包括新兴的 Spring Cloud Alibaba，还有华为贡献的 Apache ServiceComb，蚂蚁金服的 SOFAStack ，Oracle 的 Helidon，Redhat 的 Quarkus，基于 Scala 语言和 Akka 的 Lagom，基于 Grails 语言的 Micronaut，基于 Python 语言的 Nameko，基于 Golang 语言的 go-micro，支持多语言混编的响应式微服务框架 Vert.X，腾讯开源的 Tars，百度开源的 Apache BRPC（孵化中），微博的简化版 Dubbo 框架 Motan 等等。
配置中心：Apollo，Nacos，disconf，Spring Cloud Config，或者 Etcd、ZK、Redis 自己封装
服务注册发现：Eureka，Consul，或者 Etcd、ZK、Redis 自己封装
服务网关：Zuul/Zuul2，Spring Cloud Gateway，nginx 系列的 Open Resty 和 Kong，基于 Golang 的 fagongzi Gateway 等
容错限流：Hystrix，Sentinel，Resilience4j，或者直接用 Kong 自带的插件
消息处理：Kafka、RabbitMQ、RocketMQ，以及 Pulsar，可以使用 Sping Messaging 或者 Spring Cloud Stream 来简化处理
链路监控与日志：开源的链路技术有 CAT、Pinpoint、Skywalking、Zipkin、Jaeger 等，也可以考虑用商业的 APM（比如听云 APM、OneAPM、App Dynamic 等），日志可以用 ELK
认证与授权：比如要支持 OAuth2、LDAP，传统的自定义 BRAC 等，可以选择 Spring Security 或者 Apache Shiro 等

Sping Cloud 与 Apache Dubbo、Spring Cloud Alibaba

Spring Cloud 是一个较为成熟的微服务框架，定位为开发人员提供工具，以快速构建分布式系统中的某些常见模式（例如，配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁，Leader 选举，分布式会话，群集状态）。其技术栈大致如下：

微服务架构深度解析与最佳实践-第二部分：四个特点和六个能力、常见框架

可以看到很多组件都是由 Netflix 贡献的。

而 Apache Dubbo 定位是一款高性能、轻量级的开源 Java RPC 框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。所以，我们可以看到 Dubbo 提供的能力只是 Spring Cloud 的一部分子集。

同时 Dubbo 项目重新维护以后，捐献给了 Apache，项目的导师就是 Spring Cloud 的核心人员。自这时候起 Dubbo 项目就开始在适合 Spring Cloud 体系，结果就是 Alibaba 也基于自己的一系列开源组件和技术，实现了 Spring Cloud Alibaba，并顺利从 Spring Cloud 孵化器毕业。详见：https://spring.io/projects/spring-cloud-alibaba

Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。主要功能和开源技术栈：

服务限流降级（Sentinel）：默认支持 WebServlet、WebFlux, OpenFeign、RestTemplate、Spring Cloud Gateway, Zuul, Dubbo 和 RocketMQ 限流降级功能的接入，可以在运行时通过控制台实时修改限流降级规则，还支持查看限流降级 Metrics 监控。
服务注册与发现（Nacos）：适配 Spring Cloud 服务注册与发现标准，默认集成了 Ribbon 的支持。
分布式配置管理（Nacos）：支持分布式系统中的外部化配置，配置更改时自动刷新。
消息驱动能力（Apache RocketMQ）：基于 Spring Cloud Stream 为微服务应用构建消息驱动能力。
分布式事务（Seata）：使用 @GlobalTransactional 注解，高效并且对业务零侵入地解决分布式事务问题。

可以看到，基本上功能都比较完备了。

原文 https://blog.csdn.net/KimmKing/article/details/105774896

正文到此结束