导图社区 微服务设计模式-逃离单体炼狱
《微服务架构设计模式》第一章的读书笔记,有需求的可以拿去借鉴一下。
社区模板帮助中心,点此进入>>
互联网9大思维
组织架构-单商户商城webAPP 思维导图。
域控上线
python思维导图
css
CSS
计算机操作系统思维导图
计算机组成原理
IMX6UL(A7)
考试学情分析系统
单体架构与微服务架构
单体架构
优点
开发容易
易于进行大规模修改
测试简单直观
部署简单明了
容易横向扩展
缺点
过高的复杂性
开发速度缓慢:过大的项目会让编译器的速度变慢
代码提交到实际部署,周期长容易出错
难以扩展:在某些情况下应用的不同模块对资源的需求是相互冲突的
缺乏可靠性:因为程序体积太大,无法进行全面和彻底的测试
需要使用某个已经过时的技术栈
微服务架构
扩展立方体和服务
X轴扩展:在多个实例之间实现请求的负载均衡
z轴扩展 根据请求的属性路由请求
Y轴扩展:根据功能把应用拆分为服务
定义:把应用程序功能性的分解为一组服务的架构风格
使大型的复杂应用程序可以持续交付和持续部署
每个服务都相对较小 并容易维护
服务可以独立部署
服务可以独立扩展
微服务架构可以实现团队的自治
更容易实验和采纳新的技术
更好的容错性
服务的拆分和定义是一项挑战
分布式系统带来的各种复杂性使开发测试部署变得困难
服务间通信
故障处理
服务不可用或高延迟
跨服务事务和查询
自动化测试
运维复杂性
当部署跨多个服务的功能时,需要协调多个开发团队。
开发者需要考虑到什么阶段使用微服务架构?
微服务架构的模式语言
模式和模式语言
模式:针对特定上下文中发生的问题的可重用解决方案
模式语言:解决特定领域内问题的相关模式的集合
模式结构的三个组成部分
需求:描述了必须解决的问题和围绕这个问题的特定上下文环境
结果上下文
说明:采用模式后可能带来的结果
好处:使用它的好处和他解决了什么需求
缺点:使用它的弊端和他们没有解决什么需求
问题:使用这个模式所引入的新问题
相关模式
说明:他描述了这个模式和其他模式之间的关系
前导:催生这个模式的需求的模式
后续:用来解决当前模式引入的新问题的模式
替代:当前模式的替代模式提供了其他的解决方案
泛化:针对一个问题的一般性解决方案
特化:针对特定模式的具体解决方案
应用相关模式组
分解
数据库架构
查询:从多个服务的数据源获取数据,CQRS
维护数据一致性:使用Saga模式来确保数据的一致性
测试
消费端驱动的契约测试:验证服务满足客户端所期望的功能
消费端契约测试:验证服务的客户端可以正常与服务通信
服务组件测试:在隔离的环境中测试服务
可观测性:故障诊断排错
健康检查api
日志聚合
分布式追踪
异常跟踪
应用指标
审计日志
应用基础措施相关模式组
可观测性
边界安全
安全性:访问令牌模式
事务性消息:将消息发送,事件发布这样的动作与更新业务数据的数据库操作集成
通信风格:使用哪一类进程间通信机制
可靠性:在服务不可用的情况下,如何保证服务之间的可靠通信
服务发现:客户端如何获取服务具体实例的ip地址
基础措施相关模式组
服务发现
外部api:应用程序的客户端如何与服务进行通信
部署: 使用基于虚拟机,容器或serverless技术的部署平台
通信模式集合:包括上面的事务性消息,通信风格,可靠性,服务发现,外部api
流程和组织
团队扩大会提升沟通成本
将团队的规模维持在8~12人
每个团队都有明确的职责 负责运维一个或多个服务
采用微服务架构后使用scrum和kanban敏捷开发和部署实践
需要积极实践持续交付和持续部署
持续交付
软件总是随时可以交付的
依赖于高水平的自动化(自动化测试)
中断次数少并且可以快速恢复
相关指标
部署频率
交付时间
平均恢复时间
变更失败率
康威定律:设计系统的组织,往往被组织的架构所限制,最终设计的结果是这些组织的沟通结构的副本