关于微服务的思考

微服务的概念最早是在2014年由Martin Fowler和James Lewis共同提出(原文链接：https://martinfowler.com/articles/microservices.html)，他们定义了微服务是由单一应用程序构成的小服务，拥有自己的进程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用HTTP API通讯。同时，服务会使用最小规模的集中管理 (例如Docker)技术，服务可以用不同的编程语言与数据库等。

特点

从微服务的定义当中，我们可以提炼出如下几个微服务的核心特点：

一组小的服务(涉及到服务拆分的粒度问题，后面会涉及)
独立进程
轻量级通信(Rest和RPC)
独立部署

利弊

微服务带来的好处：

清晰的模块边界
各自独立部署，互不影响
各个服务可选择不同的技术实现

微服务带来的弊端：

分布式复杂性(从单体到微服务，系统内部复杂度降低，同时外部复杂度增加)
数据一致性问题
运维复杂度更高
测试复杂度更高

引入时机

前期业务不复杂的情况下，不建议引入微服务。对于一个业务，一开始就应该是怎么快怎么来，快速迭代，快速验证产品。随着业务不断发展越来越复杂，整个生产力开始下降的时候，就可以开始考虑引入微服务了。

在引入微服务的时候，整体的一个思路是：选择一个非核心模块开始微服务化，将微服务整套核心基础设施落地(核心基础设施后面会涉及)，然后渐进式地去微服务化其他模块，稳步前进。

需要哪些治理环节

服务注册中心

服务通信

服务配置中心

统一网关

自动化部署

可观测性(日志Logs、监控Metrics、链路追踪Trace)

从单体架构到微服务架构的演进

单体架构

早期开发的时候，一个war包或者jar包，里面包含了一个应用的所有功能，这样的架构我们叫作单体架构。单体架构足够简单，可以快速开发和上线，适用于项目初期业务简单、用户量不大的情况。

集群和垂直化

集群：横向增加服务器，将单台机器变成由多台机器组成的集群。

垂直化：按照业务的垂直领域进行划分，降低业务的耦合度，同时提高应用的可伸缩性。

SOA

面向服务架构，核心目标是把一些通用的、会被多个上层服务调用的共享业务提取成独立的基础服务，这些被提取出来的共享服务相对来说比较独立，并且可以重用。所以在SOA中，服务是最核心的抽象手段，业务被划分为一些粗粒度的业务服务和业务流程。

SOA解决的问题：信息孤岛；共享业务重用。

微服务架构

我们可以简单地理解，多个微服务可以组成一个SOA服务。

由于SOA和微服务它们的关注点不同，就导致了它们之间有非常大的区别：

SOA关注的是服务的重用性和信息孤岛问题；
微服务关注的是业务解耦。

解耦是降低业务之间的耦合度，重用性关注的是服务的复用。

微服务架构使得服务粒度细化之后，开发运维也变得更加重要，和容器技术也结合得更加紧密。

如何实现微服务架构

服务拆分

更多的时候，大家可能都是按照业务流程 来进行服务的拆分的。除此之外，我们还可以按照性能、业务重要程度、可用性、稳定性这些维度来进行微服务的拆分，具体采取什么方式可以视具体情况而定。

那关于服务的粒度，我们应该如何把握呢？粒度太细或太粗都不太合适，粒度太细会导致开发、测试、运维更加复杂，整体性能会降低等；粒度太粗又会导致达不到我们的预期，服务之间依赖太大。这里有一个技巧：三个火枪手原则。拆分微服务的数量=服务端开发人数/3。

什么是三个火枪手原则？平均3个开发人员负责一个微服务。

为什么不是1个人？没有备份人员，一个人思维有局限。

为什么不是2个人？异常情况下一个人压力会比较大，另外两个人维护的服务复杂度可能偏低。

为什么不是4个或者更多？开发人员多了之后，每个人不一定能掌握单个服务的所有细节。

主流微服务解决方案

Spring Cloud Alibaba(目前用得比较多的方案)
Spring Cloud Netflix
SpringBoot + K8s
Dubbo

基础设施

微服务整个基础设施会包括下面这些内容，我们一起来看看。

服务接入层：服务网关；服务流控；服务降级；服务安全。
服务运行层：服务注册；服务发现；服务路由；服务容错。
技术支撑层：接口框架；分布式事务；自动化测试；容器编排；自动化部署；灰度发布；服务监控；服务跟踪。
基础设施层：配置中心；日志中心；分布式锁；消息队列。

上面说了这么多，那么它们的优先级是怎么样的呢？服务运行层 > 服务接入层 > 基础设施层 > 技术支撑层。其中微服务框架的核心是：服务注册、服务发现和服务路由。

下一代微服务架构Service Mesh

什么是Service Mesh？

Service Mesh是一种新型的用于处理服务与服务之间通信的技术，尤其适用以云原生应用形式部署的服务，能够保证服务与服务之间调用的可靠性。在实际部署时，Service Mesh 通常以轻量级的网络代理的方式跟应用的代码部署在一起，从而以应用无感知的方式实现服务治理。

Service Mesh 以轻量级的网络代理的方式与应用的代码部署在一起，用于保证服务与服务之间调用的可靠性，这与传统的微服务架构有着本质的区别，这么做主要是出于两个原因：

跨语言服务调用的需要
云原生应用服务治理的需要

Service Mesh的实现原理

Service Mesh 实现的关键就在于两点：一个是上面提到的轻量级的网络代理也叫 SideCar，它的作用就是转发服务之间的调用；一个是基于 SideCar 的服务治理也被叫作 Control Plane，它的作用是向 SideCar 发送各种指令，以完成各种服务治理功能。

1.SideCar

2.Control Plane

既然 SideCar 能实现服务之间的调用拦截功能，那么服务之间的所有流量都可以通过 SideCar 来转发，这样的话所有的 SideCar 就组成了一个服务网格，再通过一个统一的地方与各个 SideCar 交互，就能控制网格中流量的运转了，这个统一的地方就在 Sevice Mesh 中就被称为 Control Plane。

Service Mesh 在诞生不到两年的时间里取得令人瞩目的发展，Google、IBM 领导的 Istio是 Service Mesh 技术的代表之作。除吃之外还有微博的 Weibo Mesh、华为公有云 Service Mesh 以及蚂蚁金服的 SOFA Mesh 等。