微服务架构浅谈

大张哥儿

已于 2023-04-13 14:21:53 修改

阅读量118

点赞数

分类专栏：架构文章标签：微服务架构云原生系统架构

于 2023-04-10 15:36:51 首次发布

本文链接：https://blog.csdn.net/zrush/article/details/130054720

版权

架构专栏收录该内容

3 篇文章 0 订阅

订阅专栏

架构

1. 初见
2. 认知
3. 少踩些坑

1. 初见

微服务架构（Microservice Architecture）是一种架构概念，它是把一个大型的单个应用程序和服务拆分为数个甚至数十个的微型服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。

和传统架构方式相比各个服务组件可以独立维护，互不冲突，容易上线迭代，组件间相互解耦，扩展性好。当然缺点也很明显，分布式管理和维护是以系统的复杂性为代价，需要有更完善的方案设计和追踪能力才能保证线上业务稳定运行，以及线上问题能够被及时处理。

在这里插入图片描述

2. 认知

2.1 特征

分布式部署的服务
以业务为维度划分的服务
服务具有独立性。
需要自动化运维
可靠的高度容错性
能够快速演化和迭代

2.2 设计

2.2.1 做好准备

微服务的体现是模块向服务转化的方式，就是把整个单体应用里的各个模块划分好业务边界，然后把每个模块单独提取出来实现成独立的服务运行，边界处通过接口对外提供通信能力。

重写的过程可以尝试最新技术和语言框架，通信接口最好采用标准协议方式，有时需要考虑到安全性和性能也会采用私有协议通信。

有的微服务是直接面对用户的，为用户提供某个功能。只要用户用得到，就先把这个服务挖出来。然后针对性的，快速确认业务需求，快速开发迭代。

下图包含了微服务架构涉及到的相关内容，有数据，部署，分区，服务发现，网关，通信等，这些都是在方案设计中需要反复打磨的部分。
在这里插入图片描述

2.2.2 先思考，再实现

我们要有完整的思考过程，一个成功的方案设计会减少很多后续的麻烦，尽量在方案设计阶段把工作做足，我们对自己将要实现的服务组件去思考一些问题：

服务边界划分

首先明确服务要实现的业务内容，划分好业务边界，尽量减少处理逻辑和外部服务的耦合。如果是边界网关，还要考虑服务需要提供鉴权，审计，控制，外部接口等能力。
服务间通信

当前要实现的微服务组件和上下游服务组件如何进行通信。此处要结合公司具备的软件环境条件去考虑实现方案。例如公司通用组件部门有维护Kafka队列的团队，如果Kafka是备选项之一，可以直接选择使用，避免重复造轮子。

常用的通信方式有：
（1）REST（JAX-RS，Spring Boot）
（2）RPC（Thrift, Dubbo）
（3）异步消息调用(Kafka, Notify, MetaQ)

同步通信实现简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要求，只要封装了HTTP的SDK就能调用。在公司内部，如果有统一开发规范和统一服务框架时，REST开发效率优势更明显。

异步消息在分布式系统中有特别广泛应用，既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验。不过代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要实现幂等性，因为消息发送出于性能的考虑一般会有重复最后就是必须引入一个独立的broker，如果公司内部没有技术积累，也可以自己开发。
服务多实例

线上一定会涉及多实例部署的运行场景，负载调度和自动扩缩容是避不开的。首先看开发框架本身是否具备负载调度能力，我们是否还需要前置一些代理服务，调度服务等。我们前期根据业务量评估自动扩缩容是否可以延后实现，手动扩缩容花费的时间对线上业务的影响等。这些是需要我们考虑到的。

一般有两类做法，客户端做：优点是架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址。服务端做：优点是简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。具体内容可以参考ZK，Dubbo等方案。
服务挂了，如何解决

服务可靠性和容灾能力是一个比较大的话题，有读者对这个关心的话，评论区留言以后会专门去写这个专题，这里我只简单说一下。服务容灾和可靠性在整个架构设计中是比较重要的一个环节，也是比较复杂的。往往领导更关注的是用户体验，而不关心你用什么技术实现的。这里我建议大战在即，粮草先行，我们要把服务容灾能力放在首位，提高产品刚上线后的用户体验，避免产品还没开始迭代，用户都跑光了。
部署方案：集群，哨兵，双机，组管理等方式。
层级切换：网络切换，业务切换等。
容灾方式：重试机制，限流，熔断机制，负载均衡，降级（本地缓存）等。

实际使用中是多种结合的方式，在产品开发初期，可以根据实际情况选择能提供效果最明显的来实现，随着产品迭代，再逐步完善。
API Gateway

API Gateway可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Node.js的服务端。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。
通常是需要提供统一服务入口，让微服务对前台透明，接口尽量设计的通用和扩展。聚合后台的服务，节省流量，提升性能。提供安全，过滤，流控等API管理功能。