Istio-如何拆分微服务

概述

目前微服务的拆分方式众说纷纭，每家的拆分方式也不尽相同，每家说的也都很有道理，但可惜没有 银弹（没有简单的方式解决复杂的软件工程问题），在这种情况下我们只需明确 架构是演化来的，不是设计来的 这一准则便不会让我们陷入纠结的泥潭，既然如此那我们随心所欲的拆分就好了嘛，不用有太大的心里负担，以下咱们根据微服务架构的设计模式还是能够提炼出一些基本的拆分方式供我们选择和借鉴

拆分粒度

我个人认为拆分粒度越细越好，咱们可以考虑一种面向未来的架构方式去做拆分，目前下一代架构基本就定在 Servless 这一概念上了（函数即服务，函数计算，一个函数一个服务），拆分的粒度足够细的话在未来转型云架构时会变的轻松许多并且咱们势必还要实现 全程异步通信 与 全服务无状态 等

拆分方法

根据业务拆分

将系统中的业务模块按照职责范围识别出来，每个单独的业务模块拆分为一个独立的服务，例如，做一个电商系统，可以划分为 商品、交易、用户 3 个服务，也可以划分为商品、订单、支付、发货、买家、卖家 6 个服务

根据可靠性拆分

将系统中的 可靠性要求高的核心服务 和 可靠性要求低的非核心服务 拆分开来，然后重点保证核心服务的高可用，其优点如下：

• 避免非核心服务故障影响核心服务，例如，日志上报是非核心服务，某一段时间内上报量可能会非常大，如果没有拆分出来，那么就可能严重影响核心服务
• 核心服务高可用方案更简单，核心服务单独拆分出来后，涉及的数据、组件等都会更少，对其做高可用方案就简单很多，需要考虑的点较少
• 降低高可用成本，拆分后，核心服务占用的机器、带宽等资源比不拆分要少很多

根据性能拆分

将对性能压力大的模块拆出来，避免影响其他服务，而且对其做性能提升、高可用等优化都更简单高效，例如电商的抢购，排队功能的性能压力很大，就可以将其独立为一个服务

根据事务拆分

通过分解事务上的服务进行拆分，按照 事务发起者，事务参与者，事务完成者 拆分成链式调用的服务，最后由 事务协调者服务 向所有参与方发出提交或回滚命令

完整微服务架构生态

我这里给出的解决方案是 React / Vue + Spring Cloud Alibaba + Apache Dubbo + Kubernetes + Istio 的方式实现我们的完整微服务架构生态，真正意义上满足三大指标（高可用、高性能、高并发），下一代 云架构时代，以后会尝试采用 区块链 的方式实现 Servless 函数即服务架构；下面我们看一下这几套解决方案在完整微服务架构生态中起到的主要作用

React / Vue

前后分离；将 视图层 解耦出来，使用 MVVM 模式实现双向数据绑定，利用其提供的 模块化 与 虚拟 DOM 开发前端应用程序

Aapche Dubbo

高性能 Java RPC 通信框架；它在咱们微服务架构体系中仅充当 RPC 通信功能，我主要将它作用于 数据访问层，因为数据库不允许被直接访问，所以它在我们 三层架构 的最底层即可

Spring Cloud Alibaba

一站式微服务开发解决方案；我将它作用于 业务逻辑层，阿里巴巴提供的各种组件可以很好的为我们协调业务场景问题，比如 削峰填谷、熔断降级、流量控制 等

Kubernetes

容器编排管理系统；K8S 的重要性不言而喻，它是咱们实现云计算的重要工具，它有个缺点就是没有提供很好的 服务治理 能力

Istio

Service Mesh 服务网格，让你更好更轻松的解决服务治理问题；它补充了 K8S 缺失的服务治理能力，采用 Sidecar 模式为我们提供了一套 控制面，包括 Pilot (规则配置)、Mixer (策略配置)、Citadel (证书生成与下发)、Kiali (规则验证)

Spring Cloud & Kubernetes

功能比较	Spring Cloud Alibaba	Kubernetes
配置管理	Nacos	ConfigMap
服务发现	Nacos	Etcd
负载均衡	Ribbon	Service
API 网关	借用 Spring Cloud Gateway	Ingress
认证授权	借用 Spring Security oAuth2	Secrets
日志收集	ELK (LogStash)	EFK (Fluentd)
指标收集	-	Prometheus，Grafana
链路追踪	借用 Apache Skywalking	ZipKin
熔断限流	Sentinel	支持
自动扩缩容	-	支持
打包部署	Spring Boot	Docker
任务调度	Spring Batch	Jobs