[版权申明] 非商业目的注明出处可自由转载
出自：shusheng007

概述

IT世界唯有变化才是永恒的。这不微服务刚兴起没有几年，现如今已经在全力向云原生时代过度了，有人称其为后微服务时代。云原生时代的里程碑应该是从kubernetes，江湖人称K8s，在2017年底彻底赢得容器编排战争开始的吧。现如今K8s被公认为云时代的操作系统，各大云厂商都在不遗余力的推广，因为没有K8s的日子里，他们的工作基本上是将物理机房搬到了云上而已，即是自己搭机房还是别人帮你搭机房的区别。但是有了K8s他们现在都牛逼轰轰的，声称要做到硬件即软件，相信你对各种XaaS一定不会 陌生吧? IaaS(基础设施即服务)、PaaS(平台即服务)、SaaS(软件即服务) 最后Serverless（无服务），以后真的就是云的天下了。软件和硬件的界限越来越模糊了，很多以前只有靠软件才能办到的事，现在都可以在硬件上完成了，硬件彻底被云化，被抽象化了。

不管怎么说，云原生时代也是要从硬件的角度来解决微服务时代通过软件来解决的问题，让我们更加专注于业务开发，而将非业务的工作交给云厂商。以后新型民工程序员就真的名副其实了，从此你的生命中只有增删改查，直到成为API小王子，调包小能手… 最后那些买房晚的都去卖奶茶…

所以我们还是应该先整明白微服务需要解决的问题，以及使用现有框架怎么构建微服务的问题

微服务（Micoservices）

什么是微服务

微服务定义如下

微服务（Microservices）是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic）的API集相互通信。

微服务架构仍然属于已经搞了几十年的分布式架构，它之前是SOA 架构（Service-Oriented Architecture）架构。SOA注重重用，而微服务注重隔离；SOA通信管道复杂，而微服务通信简单；等等

构建微服务架构

构建微服务架构要解决的问题几乎都是分布式架构要解决的，因为它只是微服务的一种而已。在Java生态中，Spring Cloud为开发微服务的主流框架，为我们提供一站式解决方案，所以我们文中会偏重此部分功能的讨论。

搭建一套微服务系统，大概要解决如下问题：

服务划分

首先微服务的那个微就体现出了服务的规模一般来说应该较小。每个服务是以子领域来划分的，如果这个子领域特别复杂，而又无法再进一步划分子领域，那么这个服务也会比较大的。

例如最常见的电商领域，用户相关可以划分为一个子领域，同理订单相关，物流相关等都可以划分为子领域。那么每个子领域就可以构建一个微服务，由单独的团队来负责开发、测试、维护及部署，每个微服务还会有自己独有的数据库。

服务注册与发现

假设现在有UserService与OrderService两个服务, 用户下单的时候UserService就要调用OrderService,但是UserService怎么知道OrderService的地址呢？这就需要他们两将自己的地址信息都注册到一个第三方服务上去，那样他们想调用哪个服务就去这个注册中心去拿。

较为流行的框架有:

• Netflix的 Eureka1.x进入维护期，2.x 不开源

其为AP模式，即当发生网络分区时，仍然可用，但数据不保证一致

• Hashicorp的 Consul

其为CP模式

• 阿里巴巴的 Nacos

既可以选择AP模式也可以选择CP模式，国产就是这么屌！

• Apache ZooKeeper

一般是大厂基于它来开发自己的框架，小厂和作坊就别用了，上面那几个更合适

配置中心

做过开发的小伙伴应该都明白，一个应用几乎都有外部配置的，上线后我们可以通过修改配置文件进而改变应用的行为，微服务也不例外。那到了微服务这块，因为数量众多，极其分散，所以就催生了集中配置的需求。就是每个微服务都把配置文件放到一个第三方的服务上，就是这里的配置中心。

较为流行的框架有:

• 携程的 Apollo

明明是中国公司的产品，非要叫个外国名字阿波罗，真是太不自信了，从山海经里面搞个神兽多霸气！

• 阿里巴巴的 Nacos

这货多才多艺，既能做服务发现也能做配置中心。

• SpringCloud的Spring Cloud Config

不好用

API网关

这个组件也非常容易理解，可以认为是一个房间的大门，微服务都在这个房间里。如果一个请求要去调用某个微服务，它首先的过了这大门。网关可以做很多事情，例如路由、鉴权、限流、负载均衡等等与业务无关的事情。

较为流行的有：

• SpringCloud的 spring-cloud-gateway

由于Netflix的网关Zuul 2.0封源，SpringCould官方其基于netty开发的新一代网关，优势就是与spring cloud深度集成。

• Netflix的 Zuul 2.0 已经停止维护了

• Kong

The Cloud-Native API Gateway

从其定义可以看出，这货主攻云原生，和K8s配合的天衣无缝，云厂商可能比较喜欢，在应用层面可能不太合适。

• traefik

The Cloud Native Application Proxy

又是一云原生的，和kong应该是竞争对手。

流量治理

什么是流量治理呢？大概就是指容错和限流措施。因为微服务设计非常重要的一条就是不确定，设计之初就要想到某个服务可能会崩溃，可能会扩容，可能会缩容等等。所以当服务A出问题时，不能把服务B给带崩了，进而B再把C等崩了，导致服务雪崩。还要解决当流量突增后如何限流，使其不把相关服务打崩溃等问题

常见方案

• 阿里巴巴 Sentinel

A powerful flow control component enabling reliability, resilience and monitoring for microservices. (面向云原生微服务的高可用流控防护组件)

• resilience4j

Resilience4j is a fault tolerance library designed for Java8 and functional programming

受Netflix的Hystrix启发而开发的。

• Netflix的 Hystrix 已经进入维护期，只修bug

About
Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.

负载均衡

负载均衡大家应该比较熟悉了，为了高可用性，服务大部分都是集群部署，这就面临如何分配流量的问题。例如订单服务部署了三个实例，S1,S2,S3。那么用户服务访问订单服务时候就面临着将流量打到哪个实例上得问题…

SpringCloud中从应用层面解决负责均衡的库有：

• Netflix 的ribbon

Ribbon is a Inter Process Communication (remote procedure calls) library with built in software load balancers. The primary usage model involves REST calls with various serialization scheme support.

• SpringCloud 的 spring-cloud-loadbalancer

由于ribbon进入维护期，所以spring cloud 就造了一个替代品。值得注意的是他们都是客户端负载均衡,例如上面说到的用户服务访问订单服务，那么用户服务就是客户端。

可观察性

这个其实非常重要，就是解决日志，全链路追踪，度量等问题。如果没有这一套，就算你天天996也顶不住！

• 日志记录

这个应该不用多解释，谁还没记过日志啊

主流为ELK组合：

E：Elastic的 elasticsearch

Free and Open, Distributed, RESTful Search Engine

负责日志的存储与搜索

L: Elastic的 logstash

Logstash - transport and process your logs, events, or other data

负责日志的聚合与加工

K：Elastic的 kibana

负责日志的可视化展示

• 链路追踪

为了有效地进行分布式追踪，Dapper 提出了“追踪”与“跨度”两个概念。从客户端发起请求抵达系统的边界开始，记录请求流经的每一个服务，直到到向客户端返回响应为止，这整个过程就称为一次“追踪”（Trace）。由于每次 Trace 都可能会调用数量不定、坐标不定的多个服务，为了能够记录具体调用了哪些服务，以及调用的顺序、开始时点、执行时长等信息，每次开始调用服务前都要先埋入一个调用记录，这个记录称为一个“跨度”（Span）

白话就是你想弄明白这请求到底是咋走的，期间经历了什么。

常用库

• SpringCloud的 sleuth

Distributed tracing for spring cloud

警犬基于日志追踪，适用于中小型系统

• zipkin

Zipkin is a distributed tracing system

基于服务的追踪

• apache的skywalking

APM, Application Performance Monitoring System

好像是国人开源的，牛牛，其个人介绍如下

吴晟 Wu Sheng wu-sheng
@apache First Chinese Board Director. @apache member. Apache SkyWalking Founder & VP. Microsoft MVP. AliCloud MVP. Tencent Cloud TVP.

还有一种是服务网格（Service mesh）的边车代理模式，例如其具体实现平台Istio里的实现方式。现在服务网格很流行的，通过Istio可以将本文所讲的这些业务无关的功能都剥离出去，算是云原生时代的主流产品吧。

• 度量（Metrics）

度量（Metrics）的目的是揭示系统的总体运行状态。想象一下在你面前有个大仪表盘，上面显示着你整个应用的各种指标，这就是量度。

流行框架如下：

• prometheus 普罗米修斯

The Prometheus monitoring system and time series database.

负责收集应用的各种量度数据，并存库，告警。值得注意的是这哥们儿有大一统度量江湖的趋势。

• grafana

The open and composable observability and data visualization platform. Visualize metrics, logs, and traces from multiple sources like Prometheus, Loki, Elasticsearch, InfluxDB, Postgres and many more.

与prometheus配合，完成各种Metrics仪表盘显示

• micrometer

An application metrics facade for the most popular monitoring tools. Think SLF4J, but for metrics.

看它的定义量度界的SLF4J，如果你连SLF4J都不知道那就有点扯了。因为可以完成量度的工具不止Prometheus，还有很多其他的，例如Datadog, Dynatrace等等。如果不使用Micometer，当你前期选择了Datalog，后期又想换Prometheus那就比较困难了，也就是说你已经与Datalog深度绑定了。micometer就是一个各种量度工具的一个聚合面板，你的程序只与它交互，它负责与其他量度工具交互，这样你就可以随时更换量度工具了。如果Prometheus以后统一了度量江湖，它存在的意义也就没有了…

micometer属于java生态，使用springboot2可以轻松集成。可以参考这篇文章 Spring Boot app metrics - with Prometheus and Micrometer

总结

以上就是从零搭建一微服务系统所需的主要部件，其中服务注册中心，配置中心，Api网关等容易形成单点，需要以集群的方式部署，保证可靠性。

筒子们再一次注意，由于云时代加速到来，PaaS在K8s的加持下越来越完善，功能越来越强大。未来感觉是服务网格（service mesh）的天下，服务网格是一种思想，目前最主流的实现方案就是Istio。云原生时代，连Java都受到了越来越大的挑战，如果Java生态的扛把子Spring要是一步跟不上就完犊子了。云原生的到来，使得原生语言展现出了更大的优势，例如Go，而虚拟机语言，例如Java，颓势尽显，Java希望你加速进化，适应云原生时代，不然就会被时代无情的抛弃…