微服务架构的特点、优势和常见技术
微服务的四个特点和六个能力
现在让我们分析一下上一节里的各个技术大牛们阐述的技术观点，从设计开发、系统部署、测试运维和服务治理四个主要方面来考虑微服务架构的特点，那么这四个方面就可以总结为下图：
微服务架构首先是一个分布式的架构，其次我们要暴露和提供业务服务能力，然后我们需要考虑围绕这些业务能力的各种非功能性的能力。这些分散在各处的服务本身需要被管理起来，并且对服务的调用方透明，这样就有了服务的注册发现的功能需求。
同样地，每个服务可能部署了多台机器多个实例，所以，我们需要有路由和寻址的能力，做负载均衡，提升系统的扩展能力。有了这么多对外提供的不同服务接口，我们一样需要有一种机制对他们进行统一的接入控制，并把一些非业务的策略做到这个接入层，比如权限相关的，这就是服务网关。同时我们发现随着业务的发展和一些特定的运营活动，比如秒杀大促，流量会出现十倍以上的激增，这时候我们就需要考虑系统容量，服务间的强弱依赖关系，做服务降级、熔断，系统过载保护等措施。
以上这些由于微服务带来的复杂性，导致了应用配置、业务配置，都被散落到各处，所以分布式配置中心的需求也出现了。最后，系统分散部署以后，所有的调用都跨了进程，我们还需要有能在线上做链路跟踪，性能监控的一套技术，来协助我们时刻了解系统内部的状态和指标，让我们能够随时对系统进行分析和干预。这六种能力总结如下图：
微服务的优势
为什么我们要从单体系统走向微服务架构呢？我们先来看一个图。
这个图 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 孵化器毕业。详见：
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.ytso.com/309831.html