微服务架构详解

我们为什么需要微服务架构，它一定是为了解决我们某些问题才出现了。这篇文章我们讨论下微服务架构模式所解决的问题，带来的挑战，以及他的核心思想本质。

1 早期的服务架构

​

上图是一个典型的服务分层架构：
Client： 调用方是browser web或者App
应用层： 实现计算层的业务逻辑，从上游数据层获取数据，对下游Client返回html/json/File等
数据-缓存层： 提高访问数据的性能
数据-数据库层： 持久化数据层

2 它存在的问题

1. 重装单体模式
如果是电商类型的系统，以上的架构明显需要把 用户登录、商品浏览、下单、结算、支付、订单查询都实现在一个系统里面，实在笨重。

2. 流量和并发量限制
当系统的流量或并发量达到一定的阈值，比如日活跃用户数量超过百万，或者每秒请求数（QPS）达到数千甚至更高时，传统的单体架构可能难以支撑如此高的负载。

3. 迭代频率
如果业务需求变更非常频繁，例如每周两次以上甚至每天都有新的功能需要上线，那么整个系统要全量发布，不论你的模块是不是变更了。难顶哟！

4. 系统难以扩展
当系统需要快速扩展以满足业务增长时，微服务架构可以更容易地实现水平扩展。

4. 耦合度和依赖关系
如果旧系统中的模块之间存在高度的耦合和复杂的依赖关系，这可能导致维护和升级变得困难。

5. 缺失故障隔离和容错能力
如果系统中的某个模块出现故障，是否会影响到整个系统的正常运行？答案是肯定的

3 微服务架构的演进

上面的问题，明显是日益膨胀的功能模块和流量规模对单体架构系统的挑战，如果不优化，将衍生出一系列的问题。
我们可以通过微服务架构演进，对系统逐步的升级。以下是我们在业务实践过程中总结的一些经验，予以参考。

3.1 基于业务逻辑拆分

基于业务逻辑拆分相对好理解一点，典型的单一职责原则，我们将功能相近的业务整合到一个服务颗粒上。

业务领域模型拆分
举一个典型的电商业务例子。电商的业务体系庞大，涉及各方面的细节。但是我们大概能够根据业务的职能做一个拆分，比如阿里的电商中台业务，包含 用户账号子系统、商品子系统、订单子系统、客户子系统、物流子系统 等。
因为职能不同，这些领域之间包含清晰的界限，所以我们可以按照这个方向将服务于不同领域（商品域和订单域）的子系统拆成独立的服务颗粒。如下图：

​

用户群体拆分
根据用户群体做拆分，我们首先要了解自己的系统业务里的用户角色领域是否没有功能耦合，有清晰的领域界限。
比如教育信息化系统，教师的业务场景和学生的业务场景，基本比较独立，而且拆分后流量上有明显的削弱。如下图所示：

​

3.2 基于可扩展拆分

这个需要区分系统中变与不变的部分，不变的部分一般是成熟的、通用的服务功能，变的部分一般是改动比较多、需要不断满足业务迭代扩展性需要的功能。
根据二八原则，系统中经常变动的部分大约只占 20%（如 运营、活动），而剩下的 80% （用户信息、基本商品信息、物流信息 等模块的管理能力和视图界面）基本不变或极少变化。如下图所示：

​

3.3 基于可靠性拆分

核心模块拆分
我们团队在做MySQL数据库和Redis集群拆分的时候，总会把一些重要的模块独立放在一个集群上，不与其他模块混用，而这个独立的集群，服务机性能要是最好的。这样做的目的是，当重要度较低的模块发生故障时，不会影响重要度高的模块。同样的道理，我们将账号、支付等核心服务单独拆分在一个服务颗粒上，建立独立服务集群，保证资源独享，来提升可用性。 如下图所示：

​

主次链路拆分
在各个业务系统中，其实都会有主次业务链路。主业务链条，完成了业务系统中最核心的那部分工作。而次链路是保证其他基础功能的稳定运行。
以电商为例子：商品搜索->商品详情页->购物车模块->订单结算->支付业务，就是一条最简单的主链路。主链路是整个系统的核心主战场，最好的资源跟火力都要放在这里，保证不失守。
 

​

这样的拆分模式保障了核心链路的计算资源分配优先、异常容错处理优先、服务隔离保护等等。

3.4 基于性能需求拆分

根据性能需求来进行拆分。简单来说就是访问量特别大，访问频率特别高的业务，又要保证高效的响应能力，这些业务对性能的要求特别高。比如积分竞拍、低价秒杀、限量抢购。
我们要识别出某些超高并发量的业务，尽可能把这部分业务独立拆分出来。

​

4 代价

分布式系统的固有复杂性
微服务架构是基于分布式的系统，而构建分布式系统必然会带来额外的性能开销和可靠性挑战。
服务的依赖管理和测试
在单体应用中，通常使用集成测试来验证依赖是否正常。而在微服务架构中，单元测试和整条服务链路的可用性都需要关注。
有效的配置版本管理
需要引入配置的版本管理、环境管理。
自动化的部署流程
有效地构建自动化部署体系，配合服务网格、容器技术，是微服务面临的另一个挑战。
对于DevOps有更高的要求
开发者也需承担起整个服务的生命周期的责任，包括部署、链路追踪、监控。构建全功能的团队，也是一个不小的挑战。
运维成本飙升
运维主要包括配置、部署、监控与告警和日志收集四大方面。微服务架构中，每个微服务粒度都需要独立地配置、部署、监控和收集日志，成本呈指数级增长。服务化粒度越细，运维成本越高。

5 微服务架构思想本质

最终的微服务架构可能是这种状态：

​

所以我们可以看出微服务架构的本质应该有如下几个：

• 风险隔离： 高度自治和高度隔离，明显不让低等级的服务影响高等级
• 分治原理： 单个服务的吞吐始终是有限的，通过微服务拆分可以突破扩展上限，分拆流量可支撑全球化的业务，不再受机房规模甚至地域影响
• 单一职责： 单体系统逐渐演变成具有单一职责的细粒度微服务

什么是微服务架构？

微服务架构是一种将应用程序构建为一组相互连接的小型、自包含组件的方法。它就像有一组工人都在协调地工作，有着共同的目标，每个人都从特定的专业知识出发进行操作。这与之前的单体结构不同，单体结构就像有一个大人物做所有事情，并且随着应用程序变得复杂，控制起来很麻烦。

微服务架构与传统的单体架构在以下方面有所不同。

• 去中心化： 微服务将功能分散到各个独立的服务中，而单体架构则将所有功能组合在单个代码库中。
• 松耦合： 微服务通过 API 进行通信，具有高内聚和低耦合的特点，而单体应用中，组件通常是耦合且内聚的。
• 独立部署： 微服务允许在不影响整个系统正常运行的情况下更换或部署单个服务，而单体架构中的更改则需要协调部署。
• 可扩展性： 微服务可以根据用户需求独立调整，而像单体应用这样的方法则需要在整个应用程序中进行扩展。
• 故障隔离： 在微服务中，当一个服务失败时，它不会影响其他服务；而在单体服务中，一个组件的失败可能会导致整个应用程序的失败。

微服务与单体架构的全面比较

特征	微服务架构	单体架构
结构和组织
架构风格	分布式的小型独立服务集合	包含所有功能的单一统一代码库
组件耦合	通过 API 实现松散耦合和高内聚	具有直接依赖关系的紧密耦合组件
开发与部署
部署流程	独立部署单个服务	整个应用程序必须作为一个单元进行部署
技术栈	不同服务可以使用不同技术	整个应用程序采用单一技术栈
性能与可靠性
可扩展性	单个服务可以独立扩展	整个应用程序必须作为一个单元进行扩展
容错性	服务故障被隔离和控制	组件故障可能会影响整个应用程序

采用微服务架构的优缺点是什么？

这些是： 

优势：

• 可扩展性： 根据需求以一定规模开发特定服务，从而实现资源的有效利用。
• 增强的敏捷性： 独立开发和部署与更快的周期启动和变更响应能力相关。
• 技术灵活性： 为每个服务选择合适的技术，以确定其支持创新和服务优化的潜力
•  故障隔离： 为了减少服务故障的影响并提高系统稳定性。
•  可维护性： 每个小型、特定的服务都比一个单一、包罗万象的服务更容易理解、开发和管理。

挑战：

• 复杂性增加： 由于固有的复杂性，管理分布式系统比集中式系统需要更复杂的方法。
• 数据管理： 分布式数据的难点之一是控制应用程序和维护跨服务的数据一致性。
• 测试： 进行所有简单和复杂的测试至关重要，以确保所有服务的兼容性以及整个系统在部署后的稳定性。
• 沟通： 服务间的通信对于高效运行至关重要，但它会带来延迟和可能的故障区域。
• 安全性： 跨多个服务保护敏感数据需要周密的计划和执行，以避免服务漏洞。

微服务之间如何相互通信？

微服务主要通过 API（应用程序编程接口）进行交互，这些 API 描述了数据将如何交换以及以何种格式交换。这种通信模式包括：

• 同步请求-响应： 一个服务将请求转发给另一个服务，并期望后者做出响应。这很简单，但如果管理不善，可能会导致紧密耦合和性能问题。
• 异步消息传递： 服务通过消息代理交换消息，以实现解耦并获得更高的可扩展性。当需要处理大量数据或事件时，此模式最为有效。
• 事件驱动架构：服务发布事件，其他服务可以监听这些事件，从而促进松耦合和响应性。此模式非常适合需要在多个服务之间进行更新或更改的情况。

设计、开发和部署微服务的一些最佳实践是什么？

最佳实践包括： 

• 领域驱动设计 (DDD)： 将系统分解为涵盖业务能力的有限上下文，这将增强系统的可读性和可维护性。
• API优先设计:  建立清晰且文档完善的接口，以便服务在系统中进行互操作，从而确保一致性和易于集成。
• 容器化：  将服务划分为包，并放入部署容器中，以便更好地控制和 轻松扩展解决方案.
• 持续集成和持续交付 (CI/CD):  通过定期、可预测和可重复的发布来标准化构建、测试和部署。
• 监控和可观测性: 记录和监控服务状态和性能，以确保它们被良好地记录和存档，以便在出现问题时，可以轻松识别根本原因。

微服务成功应用的真实案例有哪些？

成功的微服务现实案例包括：

• Netflix：  实施了基于微服务的架构，以支持全球扩张并管理其流媒体服务的高流量。
• 亚马逊： 该电商网站在从之前的单体设计迁移后，选择了微服务架构，旨在提高适应性和多功能性。
•  优步： 微服务分别管理乘车请求、付款和司机，从而促进增长。

以上示例说明了微服务如何潜在地影响大型软件系统的创建和维护，以及它们对用户满意度的潜在影响。

重要的是要记住，微服务并非万能的解决方案。在采用这种架构风格之前，请考虑您的应用程序的具体需求和复杂性。

结论

微服务架构已成为开发现代云应用程序的重要工具。然而，它并非没有缺点，但与可扩展性、灵活性和可操作性相关的优势足以保证许多组织采用它。  

采用微服务需要仔细考虑您的需求并遵守最佳实践，以充分发挥云的潜力。

​

微服务框架对比分析

什么是微服务？

微服务是用于构建应用程序的架构风格，一个大的系统可由一个或者多个微服务组成，微服务架构可将应用拆分成多个核心功能，每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作和出现故障的时候不会相互影响，简单来说，微服务架构是把一个大的系统按照不同的业务单元分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协作，组合成一个大系统，各个小的系统是独立部署的，它们之间是松耦合的。

术语解释

微服务强调的是服务的大小，它关注的是某一个点；

微服务架构是一种架构思想，需要从整体上对软件系统进行考虑。

微服务架构图

每个业务逻辑都被分解为一个微服务，微服务之间通过REST API通信，一些微服务也会向终端用户或客户端开发API接口，但通常情况下，这些客户端并不能直接访问后台微服务，而是通过API Gateway来传递请求，API Gateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。

微服务架构发展进程

第一代微服务框架

Spring Cloud

spring Cloud为开发者提供了快速构建分布式系统的通用模型的工具（包括配置管理、服务发现、熔断器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态等）

第二代微服务框架

dubbo

Dubbo是一个阿里巴巴开源出来的一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案

第三代微服务框架

Service Mesh（服务网格）

istio是开源的Service Mesh（服务网格），Service Mesh翻译成中文就是服务网格下面会带领大家了解到底什么是istio？ 

微服务框架对比分析

参考：https://istio.cn/t/topic/33

主流微服务框架：SpringCloud、Dubbo

后起之秀的微服务框架：istio

1、框架背景对比

（1）Spring Cloud，来源于Spring Source ，具有 Spring 社区的强大背书外，还有 Netflix 强大的后盾与技术输出。Netflix 作为一家成功实践微服务架构的互联网公司，在几年前就把几乎整个微服务框架栈开源贡献给了社区，这些框架开源的整套微服务架构套件是 Spring Cloud的核心，核心部分包含如下：

 Eureka: 服务注册发现框架；Zuul: 服务网关；Karyon: 服务端框架；Ribbon: 客户端框架；Hystrix: 服务容错组件；Archaius: 服务配置组件；Servo: Metrics组件；Blitz4j: 日志组件。

（2）Dubbo 是一个分布式服务框架，是国内互联网公司开源做的比较不错的阿里开放的微服务化治理框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。其核心部分包含如下（官网）:

 远程通讯: 提供对多种基于长连接的NIO框架抽象封装，包括多种线程模 型，序列化，以及“请求-响应”模式的信息交换方式；集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地址路由，动态配置等集群支持；自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

Dubbo也是采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用 Spring加载Dubbo的配置即可，Dubbo 基于Spring的Schema扩展进行加载。当然也支持官方不推荐的 API 调用方式。

（3）istio 作为用于微服务服务聚合层管理的新锐项目，是 Google、IBM、Lyft（海外共享出行公司、Uber劲敌） 首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案。目前是针对Kubernetes环境的，社区宣称在未来几个月内会为虚拟机和Cloud Foundry等其他环境增加支持。istio将流量管理添加到微服务中，并为增值功能（如安全性，监控，路由，连接管理和策略）创造了基础，具有如下功能

1. HTTP、gRPC 和 TCP 网络流量的自动负载均衡；

2.  提供了丰富的路由规则，实现细粒度的网络流量行为控制；

3.  流量加密、服务间认证，以及强身份声明；

4.  全范围（Fleet-wide）的策略执行；

5.  深度遥测和报告。

2、开源社区活跃度对比

开源社区情况：现如今企业在采用云计算首选开源，而选择一个开源框架，社区的活跃度将作为重要参考选项。

查看下在Github上的更新时间

 Spring  Cloud ：Spring Cloud · GitHub → 所有项目均更新于『1 小时』内。Dubbo ：Dubbo · GitHub → 核心项目最近更新于『一个月乃至数月』前。istio：istio · GitHub → 所有项目均更新于『30 分钟』内。

可见，项目在社区活跃度上，istio > Spring Cloud > Dubbo，结合稳定性来看，对于使用 Java 系开发业务较多的企业，Spring Cloud 是相对更优的选择，对于更多企业来说，与语言几乎无绑定的Istio也是可以好好期待一下其在社区的发展。

 

总结：结合项目背景、提供功能、社区更新活跃度，SpringCloud是目前阶段最为稳妥的可执行微服务框架方案，istio作为支持对于Kubernetes的优先支持来讲，也是一个值得关注的方案。目前对比来看，Dubbo则显得稍逊下来。