微服务概述

服务端架构的演进¶

单体架构¶

将所有的服务端功能模块打包成单个巨石型应用缺点： * 局部改动就需要重新部署，编译时间过长 * 技术栈不宜拓展 * 只能在原有的基础上进行局部的优化

垂直分层架构¶

缺点: * 垂直分层架构的系统拆分使得集群搭建变得复杂 * 涉及到的服务间调用服务之间耦合度变高，调用关系错综复杂,难以维护调用关系

SOA面向服务架构¶

当垂直架构拆分的应用越来越多的时候，出现多个应用都依赖的业务逻辑组件，并且各个应用进行交互的需要也越来越频繁，此时需要将部分通用的业务组件独立出来，并定义好服务间交互的接口，向外提供能力，让其他服务调用，SOA面向服务架构就“应运而生” 缺点： * 适用于大型软件服务企业对外提供服务的场景，对于一般的业务场景并不适用 * 其服务的定义、注册和调用都需要较为繁琐的编码或配置实现 * 业务总线容易导致系统的单点风险并拖累整体性能

微服务架构¶

特点： * 系统服务层完全独立出来，并将服务层抽取为一个个的微服务 * 微服务遵循单一原则 * 微服务之间采用RESTful等轻量协议通信 * 微服务一般使用容器技术部署，运行在自己的独立的进程中，合理分配其所需的系统资源 * 每个微服务都有自己独立的业务开发活动和周期缺点： * 拆分的服务实例不能过多 * 服务之间相互依赖，可能形成复杂的依赖链条 * 服务实例之间交互需要处理分布式事务、调用幂等性和重试等问题，开发成本高，对团队的挑战大

微服务框架的选型¶

随着微服务架构的火热，也诞生了很多微服务框架如：Java的Spring Cloud、Go语言的Go Kit和Go Micro以及Node.js的Seneca

go语言微服务框架¶

go语言的独特优势： * 语法简单，上手快 * 原生支持并发 * 丰富的标准库 * 部署方便

Go-kit框架¶

go-kit提供了用于实现系统监控和弹性模式组件的库，例如日志记录、跟踪、限流和熔断等，这些库协助工程师提高微服务架构的性能和稳定性，Go-kit框架分层如图基于Go-kit的应用程序架构有三个主要的部分组成：传输层、接口层、服务层 * 传输层：用于网络通信，使用HTTP或gRPC等网络传输方式，或使用NATS等发布订阅系统相互通信，除此之外，Go-kit还支持使用AMQP和Thrift等多种网络通信模式 * 接口层：服务器和客户端的基本构建块，在Go-kit服务中的每个对外提供的接口方法都会定义为一个端点（Endpoint），以便在服务器和客户端之间进行网络通信。每个端点使用传输层通过使用HTTP或gRPC等具体通信模式对外提供服务。 * 服务层：具体的业务实现。服务层的业务逻辑包含核心业务逻辑，不会也不应该进行HTTP或gRPC等具体网络传输，或者请求和响应消息类型的编码和解码。 Go-kit在性能和拓展性等各方面表现优异。

Go Micro框架¶

Go Micro是基于Go语言实现的插件化RPC微服务框架它提供了服务发现、负载均衡、同步传输、异步通信以及事件驱动等机制并尝试去简化分布式系统间的通信让开发者可以专注于自身业务逻辑的开发。如图所示三层堆栈 Go Mircro是组件化的框架，每个基础功能都有对应的接口抽象，方便拓展，还有可插拔的特点

二者对比¶

Go-kit：微服务的标准库，提供独立的包，通过这些包，开发者可以用来组建自己的应用程序，微服务架构意味着构建分布式系统，这带来了许多的挑战，Go-kit可以为多数业务场景下实施微服务软件架构提供指导和解决方案
Go Micro：是一个面向微服务的可插拔RPC 框架，可以快速启动微服务的开发，Go Micro框架提供了许多功能，无需重新“造轮子”所以开发者可以花更多的时间在需要关注的业务逻辑上但是Go Micro在快速启动微服务开发的同时，也牺牲了灵活性，并且将gRPC强制为默认通信类型更换组件不如Go Kit简便

云原生与微服务架构的关系¶

从云原生定义可以知道，微服务架构是云原生的关键技术之一从本质上来说，云原生和微服务是两种不同维度的技术 * 云原生：更侧重应用程序的运行环境，它是以k8s和容器为基础的云环境 * 微服务架构：对应于应用程序的软件架构

微服务的设计¶

微服务有六大设计原则： 1. 高内聚，低耦合 2. 高度自治 3. 以业务为中心 4. 弹性设计 5. 日志和监控 6. 自动化

DDD领域驱动设计¶

设计微服务的困境¶

路径依赖法则：在人类社会中的技术演进或制度变迁均有类似于物理学中的惯性，即一旦进入某一路径（无论是好是坏），就可能对这种路径产生依赖。在这种情况下，由单体架构演进到微服务架构就变得不是那么简单了。微服务不是“小”服务，在微服务架构落地实践的过程中，工程师往往会遇到微服务的粒度与边界划分等实践问题，DDD是解决这些问题的关键技术之一，它是一套完整且系统的设计方法。

DDD¶

DDD主要用于合理地划分业务系统以及保持业务架构和系统架构的一致性这两个领域，DDD可以有效地根据业务对复杂软件系统进行拆解，微服务架构和DDD相得益彰

四层架构¶

以购物车下单为例： * 用户界面：提供下单接口 * 应用层：业务逻辑的整合 * 领域层：业务逻辑的实现和封装 * 基础设施层：底层数据库

领域和子域¶

一个业务中的所有内容构成了这个业务系统唯一的领域，，其划分的子业务就是子域核心域：顾名思义支撑子域：支撑核心域的实现通用子域：耦合的部分，如用户鉴权等

限界上下文和通用语言¶

限界上下文和子域一一对应，将限界上下文中的所有概念集中在一起，我们创建一套通用的语言，相关人员使用通用语言直接交流

团队管理¶

从层级职能组织变为小团体集群组织

Service Mesh¶

诞生背景¶

微服务架构的复杂性：在微服务架构中，微服务组件复杂、上手门槛比较高成为了痛点问题，对于业务开发人员来说，微服务仅仅是手段，不是最终的目标，我们需要对业务开发人员“屏蔽”微服务的基础组件，使得微服务之间的通信对于业务开发人员透明为了应对这个问题，有些实践是利用API网关接收请求，网关作为代理处理外部服务的请求，并提供服务注册与发现、负载均衡、日志监控、容错等功能，它可以解决从用户到各个后端服务的流量问题，而我们需要的是一个完整的贯穿整个请求周期的方案，或者至少是一些能够与API网关互补的方案和工具
微服务本身的挑战：自身引入的复杂度，版本的兼容性等服务间通信是最需要解决的问题 serice Mesh通过独立进程的方式隔离微服务基础组件对这个独立进程升级、运维要比传统的微服务方式简单得多

三种组件¶

Istio¶

由google、IBM和Lyft合作开源，基本只支持在kubernetes运行

Linkerd¶

由两部分控制平面和数据平面两个方面的架构

Envoy¶

C++编写