微服务架构设计是大型网站的必经之路，也是大厂重点考察对象，下面我就全面来详解微服务架构设计@mikechen
本篇已收于mikechen原创超30万字《阿里架构师进阶专题合集》里面。
微服务架构设计
微服务架构是一种软件开发方法，指的是：将单个应用程序分解成一组小型服务，每个服务独立运行，并通过轻量级机制进行通信。
如下图所示：
这里会涉及到微服务架构设计的特点、和原则，如下：
1、独立部署
首先，每个微服务独立部署，不会影响其他服务；
并且，团队可以独立开发、测试、和部署各个服务，自己专注自己的事情。
2、单一职责
每个微服务，只负责一个特定的业务功能，职责尽量专一。
比如：我是商品业务的，我就专注于商品业务的事情，我是订单业务，就专注于订单业务...，以此类推。
3、自治性
每个微服务，拥有自己的数据库、和数据存储逻辑，最好是按照业务来拆分。
比如：业务代码是独立的，以及对应的业务数据库最好也是一套独立的。
3、分布式通信
微服务之间通过分布式通信机制来通信，（比如：HTTP、gRPC...等）进行通信，这就是典型的分布式通信场景。
这里也一定会涉及到性能的问题，所以很多微服务框架，比如：Dubbo更愿意自定义TCP协议来解决。
4.技术异构
不同的微服务，可以使用不同的技术栈，可以是不同的技术团队来维护。
比如：不同的编程语言，比如：我是Java的，别的团队是go的、以及php的...等等，不同的技术团队来维护微服务。
5.架构模式
不同的微服务，可以根据自己的情况来选择适合自己的模式，比如：聚合设计模式、代理设计模式...等等。
聚合设计模式
在微服务架构中，聚合设计模式（Composition Design Pattern）：是指通过组合多个微服务，来实现复杂业务功能。
如下图左侧所示：
这种架构设计模式，最主要的优点就是：简化客户端、与后端的交互，统一管理认证、限流、缓存......等功能。
代理设计模式
在微服务架构中，代理设计模式（Proxy Pattern），是一种常见的模式，用于增强、或控制对微服务的访问。
这种模式：通过在客户端、和微服务之间引入一个代理层，来实现各种功能。
代理设计模式，最典型的实现方式就是：API网关。
API 网关模式是一种集中式代理模式，客户端通过 API 网关来访问微服务。
如下图所示：
具备以下的特征:
简化客户端、与后端微服务的交互；
集中处理安全、认证......等跨领域问题。
异步消息传递设计模式
在微服务架构中，选择异步消息通信，可以帮助解决同步通信中，可能遇到的一些性能、和可扩展性问题。
如下图所示：
在一些业务场景，如果采用同步通信，可能导致服务间的紧耦合，因为一个服务必须，等待另一个服务的响应。
而且，请求方发送请求并等待响应，整个过程是阻塞的。
以及，在长时间操作、或高延迟的情况下，可能会导致性能瓶颈。
在这样的业务场景下，可以采用异步消息通信。
这样服务之间松耦合，因为服务不需要等待响应，可以继续执行其他任务。
可以更好地处理长时间操作、或高延迟的场景，提升系统的可扩展性、和响应能力。
数据共享设计模式
从单体应用，到微服务架构的迁移是一个复杂的过程，涉及到多个方面的调整、和优化。
比如：最典型的微服务架构场景，就是按照业务的不同来拆分微服务，以及按照业务的特征，来构建独立的数据库、以及服务器。
这是最理想的状态，但是，在实施的过程中，可以根据自己的业务情况来调整。
比如：可以先通过共享数据库的方式来过渡，如下图所示：
在迁移过程中，暂时共享数据库，可以避免服务间的复杂数据同步问题。
本篇已收于mikechen原创超30万字《阿里架构师进阶专题合集》里面。
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/hd-wfwjg/4278.html