微服务的设计原则

分布式服务架构 专栏收录该内容
3 篇文章 0 订阅

一 前言

  微服务是一种架构风格。一个大型的复杂软件应用,由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好的完成该任务。那么关于微服务的设计原则有哪些呢?如下:

  • AKF 拆分原则
  • 前后端分离原则
  • 无状态服务
  • RestFul 的通信风格

二 AKF 拆分原则

   有句挺流行的话:没有什么事是一顿烧烤解决不了的,如果有,那就两顿....。这跟我们之前设计可扩展的系统架构的理念很相像,

通过加机器就可以解决容量和可用性问题 。( 如果一台不行那就两台) 。这个理念在当前也得到了广泛的认可!对于一个规模迅速增长的系统而言,容量和性能问题当然是首当其冲的。但是随着现在业务的更迭不穷以及功能模块的不断拓展,许多系统在设计的时候并没有充分考虑到这一点,所以如果架构重设,必然会导致财力跟人力的浪费。对此,《可扩展的艺术》一书提出了一
个更加系统的可扩展模型—— AKF  可扩展立方(Scalability Cube)。这个立方体中沿着三个坐标轴设置分别为:X、Y、Z。

  • Y 轴(功能) —— 关注应用中功能划分,基于不同的业务拆分
  • X 轴(水平扩展) —— 关注水平扩展,也就是”加机器解决问题”
  • Z 轴(数据分区) —— 关注服务和数据的优先级划分,如按地域划分

2.1  Y  轴(功能)

Y 轴扩展会将庞大的整体应用拆分为多个服务。每个服务实现一组相关的功能,如订单管理、客户管理等。在工程上常见的方案是  服务化架构(SOA) 。比如对于一个电子商务平台,我们可以拆分成不同的服务,组成下面这样的架构:

但通过观察上图容易发现,当服务数量增多时,服务调用关系变得复杂。为系统添加一个新功能,要调用的服务数也变得不可控,由此引发了服务管理上的混乱。所以,一般情况下,需要采用服务注册的机制形成服务网关来进行服务治理。系统的架构将变成下图所示:

2.2 X 轴(水平扩展)

X 轴扩展与我们前面朴素理念是一致的,通过绝对平等地复制服务与数据,以解决容量和可用性的问题。其实就是将微服务运行多个实例,做集群加负载均衡的模式。为了提升单个服务的可用性和容量,  对每一个服务进行 X  轴扩展划分 

2.3  Z  轴( 数据分区)

Z 轴扩展通常是指基于请求者或用户独特的需求,进行系统划分,并使得划分出来的子系统是相互隔离但又是完整的。以生产汽车的工厂来举例:福特公司为了发展在中国的业务,或者利用中国的廉价劳动力,在中国建立一个完整的子工厂,与美国工厂一样,负责完整的汽车生产。这就是一种 Z 轴扩展。

工程领域常见的 Z  轴扩展有以下两种方案:
1.单元化架构
在分布式服务设计领域,一个单元(Cell)就是满足某个分区所有业务操作的自包含闭环。如上面我们说到的 Y 轴扩展的 SOA 架构,客户端对服务端节点的选择一般是随机的,但是,如果在此加上 Z 轴扩展,那服务节点的选择将不再是随机的了,而是每个单元自成一体。如下图:


2  数据分区
为了性能数据安全上的考虑,我们将一个完整的数据集按一定的维度划分出不同的子集。 一个分区(Shard),就是是整体数据集的一个子集。比如用尾号来划分用户,那同样尾号的那部分用户就可以认为是一个分区。数据分区为一般包括以下几种数据划分的方式:
数据类型(如:业务类型)
数据范围(如:时间段,用户 ID)
数据热度(如:用户活跃度,商品热度)
按读写分(如:商品描述,商品库存)

举个例子:比如美团,滴滴遍布全国,各个城市的业务进展不太一样,所以可以根据城市来进行数据分区。

三 前后端分离原则

   这个我们应该很常见,前端做前端的事情,后端做后端的业务模块,分工更加明确。

那么前后段分离有什么好处呢?

这种分离方式有几个好处:

  • 前后端技术分离,可以由各自的专家来对各自的领域进行优化,这样前段的用户体验优化效果更好。
  • 分离模式下,前后端交互界面更清晰,就剩下了接口模型,后端的接口简洁明了,更容易维护。
  • 前端多渠道集成场景更容易实现,后端服务无需变更,采用统一的数据和模型,可以支持多个前端:例如:微信 h5 前端、PC 前端、安卓前端、IOS 前端。

四 无状态服务

     什么是状态?

     如果一个数据需要被多个服务共享,才能完成一笔交易,那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务,反之称为无状态服务。更好的说明见下图:

场景说明:例如我们以前在本地内存中建立的数据缓存、Session 缓存,到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储,让业务服务变成一个无状态的计算节点。迁移后,就可以做到按需动态伸缩,微服务应用在运行时动态增删节点,就不再需要考虑缓存数据如何同步的问题。这样对于业务的拓展起到了至关重要的作用

五 RestFul通讯风格

作为一个原则来讲本来应该是个“无状态通信原则”,在这里我们直接推荐一个实践优选的 Restful 通信风格 ,因为他有很多好处:

  1.  无状态协议 HTTP,具备先天优势,扩展能力很强。例如需要安全加密,有现成的成熟方案 HTTPS 即可。
  2.  JSON 报文序列化,轻量简单,人与机器均可读,学习成本低,搜索引擎友好。
  3. 语言无关,各大热门语言都提供成熟的 Restful API 框架,相对其他的一些RPC 框架生态更完善。

 

  • 0
    点赞
  • 0
    评论
  • 7
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

本书全面介绍了微服务的建模、集成、测试、部署和监控,通过一个虚构的公司讲解了如何建立微服务架构。主要内容包括认识微服务在保证系统设计与组织目标统一上的重要性,学会把服务集成到已有系统中,采用递增手段拆分单块大型应用,通过持续集成部署微服务,等等。 作者简介: Sam Newman 是ThoughtWorks公司的技术专家、ThoughtWorks内部系统架构师,同时还为全球的客户提供咨询服务。他在 开发和IT运维方面与全球多个领域的公司有过合作。 译者简介: 崔力强 阿里巴巴技术专家,目前专注于持续交付相关的产品开发。曾在ThoughtWorks任职多年,从事软件定制开发、敏捷软件开发的相关咨询等工作,帮助过数个团队和项目进行精益需求管理、软件设计、自动化测试和持续集成等实践。信号:blade_1986 张骏 2010年加入ThoughtWorks公司。作为开发人员、项目经理、资深敏捷教练和资深咨询师,在金融、电信和能源服务行业的大型复杂业务系统的设计、开发、管理、咨询等方面有丰富的经验。曾为国内外诸多客户提供软件设计、开发以及咨询服务。拥有10年工作经验,在Scrum、看板、规模化敏捷等方法论,以及精益需求管理、自动化测试、持续集成、领域驱动设计微服务等具体实践方面都有丰富的积累。信号:zhangjun695339 目录 · · · · · · 前言  xiv 第1章 微服务  1 1.1 什么是微服务  2 1.1.1 很小,专注于做好一件事  2 1.1.2 自治性  3 1.2 主要好处  3 1.2.1 技术异构性  3 1.2.2 弹性  4 1.2.3 扩展  5 1.2.4 简化部署  5 1.2.5 与组织结构相匹配  6 1.2.6 可组合性  6 1.2.7 对可替代性的优化  6 1.3 面向服务的架构  7 1.4 其他分解技术  7 1.4.1 共享库  8 1.4.2 模块  8 1.5 没有银弹  9 1.6 小结  10 第2章 演化式架构师  11 2.1 不准确的比较  11 2.2 架构师的演化视角  12 2.3 分区  14 2.4 一个原则性的方法  15 2.4.1 战略目标  15 2.4.2 原则  15 2.4.3 实践  16 2.4.4 将原则和实践相结合  16 2.4.5 真实世界的例子  16 2.5 要求的标准  17 2.5.1 监控  18 2.5.2 接口  18 2.5.3 架构安全性  18 2.6 代码治理  18 2.6.1 范例  19 2.6.2 裁剪服务代码模板  19 2.7 技术债务  20 2.8 例外管理  21 2.9 集中治理和领导  21 2.10 建设团队  22 2.11 小结  23 第3章 如何建模服务  24 3.1 MusicCorp简介  24 3.2 什么样的服务是好服务  25 3.2.1 松耦合  25 3.2.2 高内聚  25 3.3 限界上下文  26 3.3.1 共享的隐藏模型  26 3.3.2 模块和服务  27 3.3.3 过早划分  28 3.4 业务功能  28 3.5 逐步划分上下文  29 3.6 关于业务概念的沟通  30 3.7 技术边界  30 3.8 小结  31 第4章 集成  32 4.1 寻找理想的集成技术  32 4.1.1 避免破坏性修改  32 4.1.2 保证API的技术无关性  32 4.1.3 使你的服务易于消费方使用  33 4.1.4 隐藏内部实现细节  33 4.2 为用户创建接口  33 4.3 共享数据库  33 4.4 同步与异步  35 4.5 编排与协同  35 4.6 远程过程调用  38 4.6.1 技术的耦合  38 4.6.2 本地调用和远程调用并不相同  39 4.6.3 脆弱性  39 4.6.4 RPC很糟糕吗  40 4.7 REST  41 4.7.1 REST和HTTP  41 4.7.2 超媒体作为程序状态的引擎  42 4.7.3 JSON、XML还是其他  44 4.7.4 留心过多的约定  44 4.7.5 基于HTTP的REST的缺点  45 4.8 实现基于事件的异步协作方式  46 4.8.1 技术选择  46 4.8.2 异步架构的复杂性  47 4.9 服务即状态机  48 4.10 响应式扩展  48 4.11 微服务世界中的DRY和代码重用的危险  49 4.12 按引用访问  50 4.13 版本管理  51 4.13.1 尽可能推迟  51 4.13.2 及早发现破坏性修改  52 4.13.3 使用语义化的版本管理  53 4.13.4 不同的接口共存  53 4.13.5 同时使用多个版本的服务  54 4.14 用户界面  55 4.14.1 走向数字化  56 4.14.2 约束  56 4.14.3 API组合  57 4.14.4 UI片段的组合  57 4.14.5 为前端服务的后端  59 4.14.6 一种混合方式  60 4.15 与第三方软件集成  61 4.15.1 缺乏控制  61 4.15.2 定制化  62 4.15.3 意大利面式的集成  62 4.15.4 在自己可控的平台进行定制化  62 4.15.5 绞杀者模式  64 4.16 小结  65 第5章 分解单块系统  66 5.1 关键是接缝  66 5.2 分解MusicCorp  67 5.3 分解单块系统的原因  68 5.3.1 改变的速度  68 5.3.2 团队结构  68 5.3.3 安全  68 5.3.4 技术  68 5.4 杂乱的依赖  69 5.5 数据库  69 5.6 找到问题的关键  69 5.7 例子:打破外键关系  70 5.8 例子:共享静态数据  71 5.9 例子:共享数据  72 5.10 例子:共享表  73 5.11 重构数据库  74 5.12 事务边界  75 5.12.1 再试一次  76 5.12.2 终止整个操作  77 5.12.3 分布式事务  77 5.12.4 应该怎么办呢  78 5.13 报告  78 5.14 报告数据库  78 5.15 通过服务调用来获取数据  80 5.16 数据导出  81 5.17 事件数据导出  82 5.18 数据导出的备份  83 5.19 走向实时  84 5.20 修改的代价  84 5.21 理解根本原因  84 5.22 小结  85 第6章 部署  86 6.1 持续集成简介  86 6.2 把持续集成映射到微服务  87 6.3 构建流水线和持续交付  90 6.4 平台特定的构建物  91 6.5 操作系统构建物  92 6.6 定制化镜像  93 6.6.1 将镜像作为构建物  94 6.6.2 不可变服务器  95 6.7 环境  95 6.8 服务配置  96 6.9 服务与主机之间的映射  97 6.9.1 单主机多服务  97 6.9.2 应用程序容器  99 6.9.3 每个主机一个服务  100 6.9.4 平台即服务  101 6.10 自动化  101 6.11 从物理机到虚拟机  102 6.11.1 传统的虚拟化技术  103 6.11.2 Vagrant  104 6.11.3 Linux容器  104 6.11.4 Docker  106 6.12 一个部署接口  107 6.13 小结  109 第7章 测试  110 7.1 测试类型  110 7.2 测试范围  111 7.2.1 单元测试  112 7.2.2 服务测试  113 7.2.3 端到端测试  114 7.2.4 权衡  114 7.2.5 比例  115 7.3 实现服务测试  115 7.3.1 mock还是打桩  115 7.3.2 智能的打桩服务  116 7.4 妙的端到端测试  117 7.5 端到端测试的缺点  118 7.6 脆弱的测试  118 7.6.1 谁来写这些测试  119 7.6.2 测试多长时间  119 7.6.3 大量的堆积  120 7.6.4 元版本  120 7.7 测试场景,而不是故事  121 7.8 拯救消费者驱动的测试  121 7.8.1 Pact  123 7.8.2 关于沟通  124 7.9 还应该使用端到端测试吗  124 7.10 部署后再测试  125 7.10.1 区分部署和上线  125 7.10.2 金丝雀发布  126 7.10.3 平均修复时间胜过平均故障间隔时间  127 7.11 跨功能的测试  128 7.12 小结  129 第8章 监控  131 8.1 单一服务,单一服务器  132 8.2 单一服务,多个服务器  132 8.3 多个服务,多个服务器  133 8.4 日志,日志,更多的日志  134 8.5 多个服务的指标跟踪  135 8.6 服务指标  135 8.7 综合监控  136 8.8 关联标识  137 8.9 级联  139 8.10 标准化  139 8.11 考虑受众  140 8.12 未来  140 8.13 小结  141 第9章 安全  143 9.1 身份验证和授权  143 9.1.1 常见的单点登录实现  144 9.1.2 单点登录网关  145 9.1.3 细粒度的授权  146 9.2 服务间的身份验证和授权  146 9.2.1 在边界内允许一切  146 9.2.2 HTTP(S) 基本身份验证  147 9.2.3 使用SAML或OpenID Connect  148 9.2.4 客户端证书  148 9.2.5 HTTP之上的HMAC  149 9.2.6 API密钥  149 9.2.7 代理问题  150 9.3 静态数据的安全  152 9.3.1 使用众所周知的加密算法  152 9.3.2 一切皆与密钥相关  153 9.3.3 选择你的目标  153 9.3.4 按需解密  153 9.3.5 加密备份  153 9.4 深度防御  154 9.4.1 防火墙  154 9.4.2 日志  154 9.4.3 入侵检测(和预防)系统  154 9.4.4 网络隔离  155 9.4.5 操作系统  155 9.5 一个示例  156 9.6 保持节俭  158 9.7 人的因素  158 9.8 黄金法则  158 9.9 内建安全  159 9.10 外部验证  159 9.11 小结  159 第10章 康威定律和系统设计  161 10.1 证据  161 10.1.1 松耦合组织和紧耦合组织  162 10.1.2 Windows Vista  162 10.2 Netflix和Amazon  162 10.3 我们可以做什么  163 10.4 适应沟通途径  163 10.5 服务所有权  164 10.6 共享服务的原因  164 10.6.1 难以分割  164 10.6.2 特性团队  164 10.6.3 交付瓶颈  165 10.7 内部开源  166 10.7.1 守护者的角色  166 10.7.2 成熟  166 10.7.3 工具  167 10.8 限界上下文和团队结构  167 10.9 孤儿服务  167 10.10 案例研究:RealEstate.com.au  168 10.11 反向的康威定律  169 10.12 人  170 10.13 小结  170 第11章 规模化微服务  171 11.1 故障无处不在  171 11.2 多少是太多  172 11.3 功能降级  173 11.4 架构性安全措施  174 11.5 反脆弱的组织  175 11.5.1 超时  176 11.5.2 断路器  176 11.5.3 舱壁  178 11.5.4 隔离  179 11.6 幂等  179 11.7 扩展  180 11.7.1 更强大的主机  181 11.7.2 拆分负载  181 11.7.3 分散风险  181 11.7.4 负载均衡  182 11.7.5 基于worker的系统  184 11.7.6 重新设计  184 11.8 扩展数据库  185 11.8.1 服务的可用性和数据的持久性  185 11.8.2 扩展读取  185 11.8.3 扩展写操作  186 11.8.4 共享数据库基础设施  187 11.8.5 CQRS  187 11.9 缓存  188 11.9.1 客户端、 代理和服务器端缓存  188 11.9.2 HTTP缓存  189 11.9.3 为写使用缓存  190 11.9.4 为弹性使用缓存  190 11.9.5 隐藏源服务  191 11.9.6 保持简单  191 11.9.7 缓存中毒:一个警示  192 11.10 自动伸缩  192 11.11 CAP定理  193 11.11.1 牺牲一致性  194 11.11.2 牺牲可用性  195 11.11.3 牺牲分区容忍性  195 11.11.4 AP还是CP  196 11.11.5 这不是全部或全不  196 11.11.6 真实世界  197 11.12 服务发现  197 11.13 动态服务注册  199 11.13.1 Zookeeper  199 11.13.2 Consul  200 11.13.4 构造你自己的系统  201 11.13.5 别忘了人  201 11.14 文档服务  201 11.14.1 Swagger  202 11.14.2 HAL 和HAL浏览器  202 11.15 自描述系统  203 11.16 小结  203 第12章 总结  204 12.1 微服务原则  204 12.1.1 围绕业务概念建模  205 12.1.2 接受自动化文化  205 12.1.3 隐藏内部实现细节  205 12.1.4 让一切都去中心化  206 12.1.5 可独立部署  206 12.1.6 隔离失败  206 12.1.7 高度可观察  207 12.2 什么时候你不应该使用微服务  207 12.3 临别赠言  208 关于作者  209 关于封面  209
<p> <span style="font-family:-apple-system, system-ui, 'PingFang SC', Helvetica, Tahoma, Arial, 'Microsoft YaHei', 软雅黑, 黑体, Heiti, sans-serif, SimSun, 宋体, serif;font-size:12px;background-color:#ffffff;">1、系统全面介绍了Python的基础语法 </span> </p> <p> <span style="font-family:-apple-system, system-ui, 'PingFang SC', Helvetica, Tahoma, Arial, 'Microsoft YaHei', 软雅黑, 黑体, Heiti, sans-serif, SimSun, 宋体, serif;font-size:12px;background-color:#ffffff;">2、在课程中融入了算法思想 </span> </p> <p> <span style="font-family:-apple-system, system-ui, 'PingFang SC', Helvetica, Tahoma, Arial, 'Microsoft YaHei', 软雅黑, 黑体, Heiti, sans-serif, SimSun, 宋体, serif;font-size:12px;background-color:#ffffff;">3、帮助初学者厘清逻辑,掌握Python的主体脉络 </span> </p> <p> <span style="font-family:-apple-system, system-ui, 'PingFang SC', Helvetica, Tahoma, Arial, 'Microsoft YaHei', 软雅黑, 黑体, Heiti, sans-serif, SimSun, 宋体, serif;font-size:12px;background-color:#ffffff;">4、从全方位立体角度解析知识点 </span> </p> <p> <span style="font-family:-apple-system, system-ui, 'PingFang SC', Helvetica, Tahoma, Arial, 'Microsoft YaHei', 软雅黑, 黑体, Heiti, sans-serif, SimSun, 宋体, serif;font-size:12px;background-color:#ffffff;">5、实战案例驱动、课程包含近200个相关案例、边讲解边实操</span> </p> <p> <span style="font-family:-apple-system, system-ui, 'PingFang SC', Helvetica, Tahoma, Arial, 'Microsoft YaHei', 软雅黑, 黑体, Heiti, sans-serif, SimSun, 宋体, serif;font-size:12px;background-color:#ffffff;"><br /> </span> </p> <p> <span style="font-family:-apple-system, system-ui, 'PingFang SC', Helvetica, Tahoma, Arial, 'Microsoft YaHei', 软雅黑, 黑体, Heiti, sans-serif, SimSun, 宋体, serif;font-size:12px;background-color:#ffffff;"><img src="https://img-bss.csdnimg.cn/202107120808123109.png" alt="" /><br /> </span> </p>
©️2021 CSDN 皮肤主题: 深蓝海洋 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值