微服务设计
2019-01-28 17:08:47 0 举报AI智能生成
此思维导图为微服务架构一书的内容梳理，主要围绕微服务、架构师，架构方法论以及架构的特定等知识点一点点展开，给微服务架构师提供架构指导
作者其他创作
大纲/内容
概念
领域驱动设计
持续交付<br>
按需虚拟化
基础设施自动化
小型自治团队
大型集群
面向服务的架构
SOA
建模服务
松耦合
修改一个服务就不需要修改另一个服务<br>
限制服务间调用形式的数量
高内聚
把相关的行为聚集在一起，把不相干的行为放在另一边<br>
找到问题的边界<br>
界限上下文
共享模型
模块和服务
逐步划分上下文
业务功能
从业务的上下文提供的功能考虑组织界限
技术边界
集成
寻找理想的集成技术<br>
通信方式<br>
SOAP
RPC
REST
ProtocolBuffer
避免破坏式修改<br>
保证API的技术无关性
使服务易于消费方使用
隐藏内部实现细节
同步/异步
请求响应式
同步
基于事件<br>
协同
编排与协同
协同
基于事件
降低耦合度
需要对业务流程做好跨服务的监控
消息订阅<br>
消费者接受事件机制
微服务发布事件机制<br>
重发机制
消息医院
原则
让中间件保持简单，把业务逻辑放在自己的服务中
编排
请求/响应
可以采用RPC/REST
服务即状态机
在唯一的地方处理状态冲突<br>
版本管理
尽可能推迟
Postel法则（鲁棒性原则）<br>
宽进严出<br>
及早发现破坏性修改
使用语义化的版本管理
major.minor.patch
major
不向后兼容
minor
新功能增加
patch
缺陷修复<br>
不同接口共存
部署
CI（持续集成）/CD（持续发布）
好处
可以得到关于代码质量的某种程度的快速反馈
三个问题
是否每天签入代码到主线
是否有一组测试来验证修改
构建失败后，是否把修复CI当做第一优先级的事情来做
流水线
编译及快速测试
耗时测试
用户验收测试
性能测试
生产环境
构建物
平台特定的构建物
操作系统构建物
定制化镜像
服务与主机的映射<br>
单主机多服务
单主机单服务
平台及服务
自动化
监控
监控小的服务，聚合起来看整体
主机监控
业务数据
因素
需要知道什么
想要什么
如何消费数据
工具
nagios
new relic<br>
graphhite
suro
Riemann
级联
UUID
健康报告<br>
健康检查<br>
设计、测试<br>
分解系统
接缝
被识别出的接缝可以作为服务的边界
原因
改变的速度
团队结构
安全
技术
步骤
找到依赖
找到问题的关键
找到事务的边界
最终一致性
通过服务调用来获取数据<br>
要在拆分变得过于昂贵之前意识到要做这个拆分
测试
测试象限
验收测试
是否实现的正确的功能
探索性测试
可用性测试
单元测试
是否正确的实现了功能
非功能性测试
响应时间
可扩展性
性能测试
安全测试
测试金紫塔
单元测试
服务测试<br>
用户界面测试
端到端的测试
依赖测试
链测试
跨功能测试<br>
测试场景而不是故事
工具<br>
moker
pact
金丝雀发布
蓝/绿部署
安全
身份验证和授权
SSO
单点登录网关<br>
HTTPS
TLS
API密钥
静态数据
加密算法
使用大家都知道的算法，不要自己发明算法
按需加密
深度防御
防火墙
日志
入侵检测（防御）系统
网络隔离
康威定律
任何组织在设计一套系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致
系统设计
一个业务线内，服务间可以不接受任何限制地以任何方式来通信，<br>只要团队确定的服务守护者认为合适即可，<br>但是在业务线之间，所有的通信都必须是异步批处理。
微服务
一些协同工作的小而自治的服务<br>
特点<br>
很小，专注于做好一件事<br>
内聚性
最好在两周内可以完全重写<br>
服务的大小需要和团队结构匹配
自治性
避免多个服务部署在一台机器上
Docker<br>
服务间通过网络调用进行通信
避免紧耦合<br>
保证技术的选择不被限制
修改一个服务进行部署，对其他服务不产生影响
SOA的一种特性方法
优势
更快的交付软件
更多机会尝试新技术
技术异构性
在不同的服务中使用合适的技术
弹性
很好的处理服务的不可用和功能降级问题<br>
扩展
只对需要扩展的服务进行扩展<br>
简化部署<br>
各个服务的部署独立
处理问题只影响一个服务
与组织结构相匹配
可组合性<br>
对可替代性的优化
对旧的系统可以部分升级替代
劣势
架构复杂
数据一致性处理复杂
增加补偿措施
CAP理论
没有银弹
架构师<br>
演进式架构师
类比城市规划师，而不是建筑师
职责
确保团队有共同的技术愿景，以帮助向客户交付他们的想要的系统
响应客户的变更需求
专注在大方向上，只在有限的情况下参与到非常具体的细节实现
保证系统适合开发人员在其上工作
关注不同区域间的事情
关注服务之间的交互，而不需要过于关注各个服务内部发生的事情
每一个服务允许团队自己选择技术
对系统设计进行取舍
战略目标<br>
建立原则
实践<br>
将原则与实践相结合
定标准
清楚的定义出一个好服务的属性<br>
监控
清楚的描述出服务的健康状态
接口
选出少数几种明确的接口技术（三种以内）<br>
RPC
REST
Protocol Buffers<br>
架构安全性<br>
代码治理
范例
提供服务代码模板
技术债务<br>
从高层次理解和权衡
例外管理
持续优化原则
集中治理和领导<br>
治理
通过评估干系人的需求，当前情况及下一步的可能性来确保企业目标的达成，通过排优先级和做决策来设定方向。对于已经达成一致的方向和目标进行监督
需要和团队一起工作
建设团队
锻炼和培养成员
0 条评论
下一页
