上一篇文章我们从「存储选型」角度学习了架构师的基本能力。今天将从存储的上一层「服务维度」学习架构师的第二项常用能力——微服务设计与治理。如何设计合理的微服务架构？如何保持微服务健康运行？这是我们对微服务进行架构设计过程中非常关注的两个问题。本文对微服务的生命周期定义了七个阶段，如下图所示。 围绕这七个阶段总结了16条常用原则。1、微服务规划原则1: 按照业务能力（business cap
目录文章目录目录请求驱动分布式运行时可信安全请求驱动请求驱动，也就是支持基于请求的动态弹性伸缩并且简化请求处理逻辑。有些同学可能把这个模型称之为 Event-driven，也就是事件驱动，但是请求驱动实际是事件驱动中的一个分支。
原创
2021-07-14 15:32:31
376阅读
目录文章目录目录请求驱动分布式运行时可信安全请求驱动请求驱动，也就是支持基于请求的动态弹性伸缩并且简化请求处理逻辑。有些同学可能把这个模型称之为 Event-driven，也就是事件驱动，但是请求驱动实际是事件驱动中的一个分支。什么是请求驱动呢？从传统的微服务架构看，当一个外部系统请求进来后，一般都会经过一个 L4/L7 的负载均衡，然后给到不同的微服务实例上面。
原创
2022-02-09 10:16:33
342阅读
AKF拆分原则业界对于可扩展系统架构设计有一个朴素的理念：通过加机器就可以解决容量和可用性问题。这一理念在云计算概念疯狂流行的今天，得到了广泛的认可，对于一个规模迅速增长的系统而言，容量...
转载
2021-06-15 17:54:18
451阅读
一、AKF拆分原则 业界对于可扩展系统架构设计有一个朴素的理念：通过加机器就可以解决容量和可用性问题。 这一理念在云计算概念疯狂流行的今天，得到了广泛的认可，对于一个规模迅速增长的系统而言，容量和性能问题当然是首当其冲的。但随着时间的向前，系统规模的增长，除了面对性能与容量的问题外，还要面对功能与模
转载
2019-06-05 10:54:00
380阅读
2评论
微服务架构是一种分布式系统架构，它将应用程序划分为小的、自治的服务，每个服务都可以独立部署、伸缩和更新。微服务的设计原则包括：1、单一职责原则（SRP）：每个微服务应该只负责一件事情，即具有单一的职责。2、开放/封闭原则（OCP）：微服务应该对扩展开放，对修改封闭。这意味着在需要添加新功能时，应该通过添加新服务来实现，而不是修改现有的服务。3、服务自治性原则（SAP）：每个微服务都应该是自治的，即
# 微服务架构设计原则
## 概述
微服务架构是一种软件设计和开发方法，将一个应用程序拆分为一组小型、独立的服务。每个服务都可以独立部署、扩展和管理，以实现更高的灵活性和可扩展性。在本文中，我将向你介绍微服务架构的设计原则，并指导你如何实现。
## 甘特图
```mermaid
gantt
dateFormat YYYY-MM-DD
title 微服务架构设计流程
AKF拆分原则业界对于可扩展系统架构设计有一个朴素的理念：通过加机器就可以解决容量和可用性问题。这一理念在云计算概念疯狂流行的今天，得到了广泛的认可，对于一个规模迅速增长的系统而言，容量和性能问题当然是首当其冲的。但随着时间的向前，系统规模的增长，除了面对性能与容量的问题外，还要面对功能与模块数量上的增长带来的系统复杂性问题以及业务的变化带来的提供差异化服务的问题。然而许多系统在架构设计时为充分考
原创
2021-12-31 15:08:47
178阅读
调用链中的异常处理假设微服务serviceA的接口interfaceA被微服务serviceB调用，如果interfaceA在调用过程中会抛出异常，那么是否该将该异常以状态码传给serviceB呢？对于RPC来说（如Feign），会自动将被调用的远程接口的异常在调用方以异常抛出；对于Rest Api来说，可以将异常包装到response的out中。 我建议serviceB在调用interface
原创
2023-02-02 21:42:47
63阅读
我们前两篇文章介绍了nacos在服务注册发现和分布式配置方面的作用。在实际生产中使用nacos你就会体会到nacos是多么的方便，基于nacos的服务注册能力可以做优雅停服功能，从此我们发版上线就不必非要等到半夜才能发布。只要随时找个业务低峰发布对应的服务集群即可。接下来我们看一下nacos的原理。Nacos 服务注册与发现原理分析nacos的功能之一就是作为服务注册发现模块也就是我们常说的注册中
在云原生架构应用的开发中，如何拆分微服务，微服务的粒度要做到多细一直都是架构师们所面临的问题。其实这个问题一直没有正确的答案，这里给出几个指导原则帮助大家在规划微服务的时候进行参考。围绕业务域进行服务的建模微服务拆分的目标并不是让你的服务尽可能的小，“微”服务名字具有误导性。构建一个服务所编写代码量并不是衡量一个服务大小的原则，代码写的多也不是服务会有错误的标志，有时候“重”一些的服务有必要的。微
在微服务架构的设计过程中，首先需要通过统一的API网关对外提供服务，各微服务之间通过REST或gRPC协议通信。单个微服务可以调用多个不同的微服务来完成自己的功能，同时每个微服务都需要有自己独立的数据存储。微服务的部署、运维等需要通过自动化的手段来实现。服务注册中心一个服务可以有多个实例，但如何知道这个服务有哪些实例呢？为了减少手工维护的麻烦，需要有一个服务注册中心来完成相关的管理工作。每个服务实
原创
2022-12-06 08:56:09
139阅读
原创
精选
2022-04-15 22:26:53
2616阅读
点赞
本文是这一系列文章的第二篇，将介绍服务的交互。（本系列第一篇）服务的交互微服务架构提倡有许多职责单一的小服务组成，这些服务之间互相交互。然而这就造成了一系列的问题，比如：服务之间如何发现彼此？是否采用统一的协议？如果一个服务无法与其他服务通信会怎样？我会在接下来的内容里讨论部分相关话题通信协议随着服务数量越来越多，在服务间使用标准化通信方法愈加重要。由于服务不一定使用相同语言编写，通信协议的选择必
微服务架构演进过程最早是应用是单块架构，后来为了具备一定的扩展和可靠性，就有了垂直架构，也就是加了个负载均衡，接下来是前几年比较火的SOA，主要讲了应用系统之间如何集成和互通，而到现在的微服务架构则是进一步在探讨一个应用系统该如何设计才能够更好的开发、管理更加灵活高效。微服务架构的基本思想就是“围绕业务领域组件来创建应用，让应用可以独立的开发、管理和加速”。微服务架构的好处四个方面的优点： 每个
微服务的拆分与设计原则
原创
2023-03-31 21:13:50
225阅读
点赞
做微服务开发的第一步，也是最重要的一步，是服务拆分。通过服务划分，可以得到各个单一功能的服务。跟着就要设计系统了，在微服务系统的设计中，需要考虑一些原则。
原创
精选
2022-08-16 22:44:43
5000阅读
点赞
微服务设计的六大原则1. 高耦合低内聚单一职责轻量级通信服务间的契约紧密关联的事务应该放在一起，每个服务是针对一个单一职责的业务能力的封装，专注做好一项职责，也只会因为该职责的变化而进行修改。服务之间通过轻量级的通信方式进行通信，使得服务间相对独立，处于低耦合的状态。2. 高度自治能独立开发、部署和发布进程隔离独立的代码库、流水线服务独立部署运行和扩展，每个服务能够独立部署并运行在独立的进程内。这
1、微服务就是一些协同工作小而自治的服务，很小，但是专注于做好一件事。微服务的目的就是有效的拆分应用，实现敏捷开发和部署。单块系统内，通常会参照单一设计模式，建立抽象层后者模块来保证内聚性。微服务将这个理念应用在独立的服务上，根据业务的便捷来确定服务的边界，这样很容易确认某个功能的代码应该放在哪里。微服务保证是一个独立的自治服务，服务之间通过网络调用进行通信，从而加强服务的隔离性微服务可以帮
