浅谈微服务架构

微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。可以理解每个微服务就是单独的服务，每个微服务只做特定的一些事情。

• 传统的服务与微服务有什么区别

传统的服务一般被称为单体式开发(Monolithic), 所有的功能打包在一个WAR中，基本上所有的功能都在内部，包含在一个容器中，内含DO/DAO,、Service等所有的逻辑。

               

优点：

①开发简单，集中式管理

②基本不会重复开发

③功能都在本地，没有分布式的管理和调用消耗

缺点：

1、效率低：开发都在同一个项目改代码，相互等待，冲突不断

2、维护难：代码功功能耦合在一起，新人不知道何从下手

3、不灵活：构建时间长，任何小修改都要重构整个项目，耗时

4、稳定性差：一个微小的问题，都可能导致整个应用挂掉

5、扩展性不够：无法满足高并发下的业务需求

常见的系统架构遵循的三个标准和业务驱动力：

1、提高敏捷性：及时响应业务需求，促进企业发展

2、提升用户体验：提升用户体验，减少用户流失

3、降低成本：降低增加产品、客户或业务方案的成本

基于微服务的设计

 

微服务的具体特征

1、一些列的独立的服务共同组成系统

2、单独部署，跑在自己的进程中

3、每个服务为独立的业务开发

4、分布式管理

5、非常强调隔离性

大概的标准：

1、分布式服务组成的系统

2、按照业务，而不是技术来划分组织

3、做有生命的产品而不是项目

4、强服务个体和弱通信（ Smart endpoints and dumb pipes ）

5、自动化运维（ DevOps ）

6、高度容错性

7、快速演化和迭代

微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，

把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然 后单独布署。 它通常不依赖其他服务。微服务中常用的API Gateway的模式主要目的也不是重用代码，

而是减少客户端和服务间的往来。API gateway模式不等同与Facade模式(是一种可以隐藏子系统复杂性的模式，通过重新组合各类及程序单元，对外提供统一的接口/界面)，可以使用如future（异步调用）之类的调用，甚至返回不完整数据。

• 客户端如何访问微服务

一般在后台N个服务和UI之间一般会一个代理或者叫API Gateway，他的作用包括：

① 提供统一服务入口，让微服务对前台透明

② 聚合后台的服务，节省流量，提升性能

③ 提供安全，过滤，流控等API管理功能

API Gateway可以是一个软硬一体的盒子、可以是一个自定义的MVC的框架、但是目前最多的是云原生的service

 

• 微服务如何互相访问

本次说明的为python实现微服务之间的互相调用，不存在虚拟机之间调用。

同步调用：

1. REST
2. RPC

异步消息调用(Kafka, Redis, RabbitMQ)

 

• 多微服务发现与负载

在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知？服务如何管理？

下线通知：

注册到消息通知，或者通过心跳维持长链接，实时更新链接信息。

当服务下线时，通知给服务客户端。

服务挂了，如何解决：

Monolithic方式开发一个很大的风险是，把所有鸡蛋放在一个篮子里，一荣俱荣，一损俱损。而分布式最大的特性就是网络是不可靠的。通过微服务拆分能降低这个风险，没有100%做到服务稳定，但尽量做到99%的服务都能瞬间被调用，常用的做法有：

1. 重试机制
2. 限流
3. 熔断机制
4. 负载均衡
5. 降级（本地缓存）

• 微服务常见的设计模式

微服务架构需要考虑的问题，包括：

1、API Gateway

2、服务间调用

3、服务发现

4、服务容错

5、服务部署

6、数据调用

六种常见的微服务架构设计模式：

1. 聚合器微服务设计模式

 

每个服务都有自己的缓存和数据库。如果聚合器是一个组合服务，那么它也有自己的缓存和数据库。聚合器可以沿X轴和Z轴独立扩展

2. 代理式微服务设计模式

 

在这种模式下，客户端并不聚合数据，但会根据业务需求的差别调用不同的微服务。代理仅仅委派请求，也可以进行数据转换工作

3. 链式微服务设计模式

 

在这种模式下，服务A接收到请求后会与服务B进行通信，类似地，服务B会同服务C进行通信。所有服务都使用同步消息传递。在整个链式调用完成之前，客户端会一直阻塞。

因此，服务调用链不宜过长，以免客户端长时间等待

4. 分支微服务设计模式

 

这种模式是聚合器模式的扩展，允许同时调用两个微服务链

5. 数据共享微服务设计模式

 

自治是微服务的设计原则之一，就是说微服务是全栈式服务。但在重构现有的单体应用时，SQL数据库反规范化可能会导致数据重复和不一致。

因此，在单体应用到微服务架构的过渡阶段，可以使用这种设计模式

6. 异步消息传递微服务设计模式

 

虽然REST设计模式非常流行，但它是同步的，会造成阻塞。因此部分基于微服务的架构可以选择使用消息队列代替REST请求/响应

一、微服务的优点：

复杂度可控，独立按需扩展，技术选型灵活，容错，可用性高

1. 它解决了复杂性的问题。它会将一种怪异的整体应用程序分解成一组服务。虽然功能总量不变，但应用程序已分解为可管理的块或服务。每个服务都以RPC或消息驱动API形式定义了一个明确的边界；Microservice架构模式实现了一个模块化水平

2. 这种架构使每个服务都能够由专注于该服务的团队独立开发。开发人员可以自由选择任何有用的技术，只要该服务符合API合同。当然，大多数组织都希望避免完全无政府状态并限制技术选择。然而，这种自由意味着开发人员不再有义务使用在新项目开始时存在的可能过时的技术。在编写新服务时，可以选择使用当前的技术。此外，由于服务相对较小，因此使用当前技术重写旧服务变得可行

3. Microservice架构模式使每个微服务都能独立部署。开发人员不需要协调部署本地服务的变更。这些变化可以在测试后尽快部署。

4. Microservice架构模式使每个服务都可以独立调整。可以仅部署满足其容量和可用性限制的每个服务的实例数。可以使用最符合服务资源要求的硬件

二、微服务的缺点

多服务运维难度，系统部署依赖，服务间通信成本，数据一致性，系统集成测试，重复工作，性能监控等

1.微服务器的另一个主要缺点是分布式系统而产生的复杂性。开发人员需要选择和实现基于消息传递或RPC的进程间通信机制。此外，还必须编写代码来处理部分故障，因为请求的目的地可能很慢或不可用。

2.微服务器的另一个挑战是分区数据库架构。更新多个业务实体的业务交易是相当普遍的。但是，在基于微服务器的应用程序中，需要更新不同服务所拥有的多个数据库。使用分布式事务通常不是一个选择，而不仅仅是因为CAP定理。许多今天高度可扩展的NoSQL数据库都不支持。所以不得不使用最终的一致性方法，这对开发来说具挑战性。

3.测试微服务应用程序也更复杂。服务类似的测试类将需要启动该服务及其所依赖的任何服务（或至少为这些服务配置存根）。再次，重要的是不要低估这样做的复杂性。开发人员更好地控制部署方法，并实现高水平的自动化。另外针对压力测试也很复杂，因为所有的功能全部都拆分了出来，从整体的性能来看很不好确定到底能支撑多大的请求与数据量，如果针对单个服务进行测试又不好完整的体现出整个项目的健壮性。所以在测试当中需要测试人员逐步的分析各个服务之间的运行情况。

• Python常见微服务编写

Flask：轻量级的Web应用程序框架，适合构建小型微服务，支持REST API开发，可与其他的Python库和框架无缝集成。

Fast API：快速的高性能Web框架，支持异步请求处理和类型注释，提供了自动生成API文档的功能。FastAPI可以作为flask的替代品，用于构建中小型微服务。

Nameko: python的微服务框架，可以轻松建立起一个微型服务，使用RPC和事件驱动方式进行服务函数调用，支持异步通信和消息传递模式。