《微服务设计》读书笔记（上）
2024-01-24 08:09:04 0 举报AI智能生成
登录查看完整内容
《微服务设计》读书笔记（上）
作者其他创作
大纲/内容
对外提供一个简单的API接口，逻辑的复杂性在内部解决
通常通过创建一个抽象层或者模块来保证代码的内聚性
单一职责原则
微服务将单一职责原则应用到服务上，根据业务边界来确定服务边界
优点：开发灵活，速度快等等
缺点：管理维护复杂等等
服务越小，微服务架构的优先和缺点越明显
多小是合适的？
1. 很小，专注于做好一件小事
服务的发布更新不会影响到调用方
2. 自治性
什么是微服务
支持不同的技术栈，更好的适应不同的场景
1. 技术异构性
处理服务不可用和功能降级的问题
2. 弹性
可以对需要扩展的微服务进行扩展
3. 扩展
各个微服务部署独立，可以快速部署
4. 简化部署
与一个个小开发团队匹配
5. 与组织结构相匹配
每个微服务都是一个小功能
多个微服务组合成一个大功能
6. 可组合性
微服务足够小，重构or新技术重写速度快，影响面小
7. 对可替代性的优化
主要好处
作者认为微服务是SOA的一个具体实现例子
面向服务的架构SOA
共享库SDK
模块
其他分解技术
微服务架构并不是通用解决方案，不能解决任何技术问题
没有银弹
第1章-微服务
软件架构师面对的需求不固定，并且经常变更，必须要适应这种变更
其他架构师（例如，建筑师）需求固定，设计好之后不会再变更
不同之处
必须改变那种从一开始就要设计出完美产品的想法
我们应该设计一个合理的框架，在这个框架下慢慢的演化出正确的系统
软件架构师的一个职责是：保证该框架是适合开发人员在上面工作的
架构师的演化视角
作为软件架构师，不应该过多的关注每个模块内细节，而是要关注模块之间如何交互
划分模块
领导者确定公司战略目标
原则不能太多（不超过10个），否则没人能记住
架构师根据战略目标确定具体的系统架构原则
架构师确保程序员在实践时遵从原则
一个原则性的方法
监控
接口
架构安全性
要求的标准
让程序员看文档的难度远远大于看代码
程序员都是懒惰的，能copy就不会自己写
架构师提供范例和服务代码模板
代码治理
指导原则不适应变化，此时要参考现实情况，做优化升级
指导原则没有问题，此时就带来了技术债务
在一些情况下，会偏离指导原则，这是无法避免的
架构师维护一个债务列表，并提供温和的指导，然后让程序员自行决定如何偿还这些技术债务
例外管理与技术债务
架构师的部分职责是治理
确保大方向正确，小方向由各个程序员自己把控
集中治理和领导
架构师需要帮助程序员提升技术，利人利己
建设团队
第2章-演化式架构师
松耦合
高内聚
什么样的服务是好服务
任何一个给定的领域都包含多个限界上下文
不需要与外部通信
需要与外部通信
每个限界上下文中的模型分为两种
每个限界上下文都有明确的接口，该接口决定了它会暴露哪些模型给其他的限界上下文
如果服务之间的边界搞错了，后面修复的代价会很大
最好能够等到系统稳定下来之后，再确定把哪些东西作为一个服务划分出去
避免过早服务拆分
限界上下文(bounded context)
从业务功能角度来确定限界上下文、划分服务是一个不错的选择
业务功能
不一定要一步到位，而且这么做大概率是失败的
先从单体系统，划分成粗粒度的上下文，然后在粗粒度的上下文里划分细粒度的上下文
不同团队之间的沟通协调是一个大问题
组织架构和软件架构是相互影响的
逐步划分上下文
对于某个功能所要做的修改，就更倾向于局限在一个单独的微服务边界之内
减小了修改的范围，并能够更快地进行部署
关于业务概念的沟通
第3章-如何建模服务
对某个服务做的一些修改不应该会导致该服务的消费方也随之发生改变
避免破坏性修改
技术栈不应该成为限制原因
保证APl的技术无关性
使用客户端库对于消费方来说很方便，但是会造成耦合的增加
使你的服务易于消费方使用
隐藏内部实现细节
寻找理想的集成技术
最快最流行的集成方式，但不是一个好的方式
这使得外部系统能够查看内部实现细节，并与其绑定在一起
最终导致：低内聚，高耦合
共享数据库
RPC的核心想法是隐藏远程调用的复杂性
RPC（远程过程调用）
常用方案是：HTTP+JSON
REST
同步方式
主要有两个部分需要考虑：微服务发布事件机制和消费者接收事件机制
尽量让中间件保持简单，而把业务逻辑放在自己的服务中
异步架构的复杂性
实现基于事件的异步协作方式
异步方式
具体场景决定采用哪种方式
通信模式：同步与异步
使用编排（orchestration）的话，我们会依赖于某个中心大脑来指导并驱动整个流程，就像管弦乐队中的指挥一样
子主题
使用协同（choreography）的话，我们仅仅会告知系统中各个部分各自的职责，而把具体怎么做的细节留给它们自己，就像芭蕾舞中每个舞者都有自己的方式，同时也会响应周围其他人
编排（orchestration）与协同（choreography）
服务即状态机
响应式扩展
在微服务内部不要违反DRY，但在跨服务的情况下可以适当违反DRY
对于微服务架构来说，客户端库必须有类似服务发现、故障模式、日志等方面的工作，来提升服务开发的效率。否则，采用微服务架构首先会带来极大的开发量，明显降低开发效率。
客户端库
微服务世界中的DRY和代码重用的危险
讨论的是：数据实体的有效性问题（是否过期）
客户端定时更新
通过事件订阅来触发更新
两种方式
按引用访问
现实中不太容易实现
尽可能推迟
及早发现破坏性修改
MAJOR的改变意味着其中包含向后不兼容的修改
MINOR的改变意味着有新功能的增加，但应该是向后兼容的
PATCH的改变代表对已有功能的缺陷修复
语义化版本管理的每一个版本号都遵循这样的格式：MAJOR.MINOR.PATCH
使用语义化的版本管理
新版本在新接口上，老版本在老接口上，让调用方慢慢从老接口迁移到新接口上，待迁移完，即可下掉老接口，完成版本升级
同时维护两个接口期间，可以让老接口调用新接口，来提升开发效率
不同的接口共存
新版本在新服务上，老版本在老服务上，让调用方满门从老服务迁移到新服务上，待迁移完成，即可下掉老服务，完成版本升级
同时维护两个服务期间，可以让老服务调用新服务，来提升开发效率
同时使用多个版本的服务
版本管理：如何做微服务的版本升级
倾向于把API设计得比较细粒度化
API入口（gateway）：将多个底层的调用会被聚合成为一个调用
界面调用API入口（gateway）
APl组合
界面由多个块组成，每个块调用不同的API入口（gateway）
一个块由一个团队负责，从前端到后端，减少沟通的代价
Ul片段的组合
可以对多个后端调用进行编排，并为不同的设备提供定制化的内容
使用服务端的聚合接口或API入口
为前端服务的后端BFF（Backends For Frontends）
用户界面
对于一般规模的组织来说，如果某个软件非常特殊，并且它是你的战略性资产的话，那就自己构建；如果不是这么特别的话，那就购买
应该自己做，还是买？
Content Management System：内容管理系统
CMS
Customer RelationshipManagement：客户关系管理
CRM
与第三方软件集成
无论如何避免数据库集成
小结：最大程度地保证微服务之间的低耦合
第4章-集成
从接缝处可以抽取出相对独立的一部分代码，对这部分代码进行修改不会影响系统的其他部分
识别出接缝不仅仅能够清理代码库，更重要的是，这些被识别出的接缝可以成为服务的边界
关键是接缝
数据库是所有杂乱依赖的源头
思考一个问题：你的系统需要多快？系统现在是多快？
一部分变慢会带来更大的好处，尤其是当这个“慢”事实上还在可接受的范围内时
对性能表示担忧问题
通过API来访问，而不是直接访问数据库
杂乱的依赖
代码
配置文件
每个服务复制一份静态数据的内容
放入一个单独的服务中
共享静态数据的处理方式
抽象出一个单独的服务处理共享数据
共享数据：特点是数据可变
保证最终一致性
再试一次
终止整个操作
避免自己去创建这套API
尽量使用现有的实现
分布式事务
若某个API出现失败了，事务如何处理？？
如果你遇到的场景确实需要保持一致性，那么尽量避免把它们放在不同的地方，一定要尽量这样做
创建一个概念来表示这个事务
举个例子，你可以创建一个叫作“处理中的订单”的概念，围绕这个概念可以把所有与订单相关的端到端操作（及相应的异常）管理起来
将数据库里的事务转变到代码中来保证
否则，尝试转变为：最终一致性
所有这些方案都会增加复杂性
事务边界
只适合一个非常简单的报表系统
通过服务调用来获取数据
一个cron任务，定时从库中导出数据，再导入到同步库中
可以创建一个大视图来做数据聚合：大宽表，导入和导出只对大宽表做
报表系统表结构的耦合的问题
数据导出
在事件发生时就给报表系统发送数据，而不是靠原有的周期性数据导出，时效性高
事件数据导出
数据导出的备份
报表数据库的问题
第5章-分解单块系统
是否每天签入代码到主线
是否有一组测试来验证修改
当构建失败后，团队是否把修复CI当作第一优先级的事情来做
测试是否真正理解CI的三个问题
把所有微服务放在同一个代码库中，并且只有一个Cl构建
将一个代码库的子目录映射到不同的构建中
每个微服务有一个源代码库和Cl构建
把持续集成映射到微服务：三种模式
CI（Continuous Integration，持续集成）
一个使用构建流水线建模的标准发布流程
快速测试：DEV环境
耗时测试：SIT环境
用户验收测试：UAT环境
性能测试：PRE环境
生产环境：PRD环境
与微保的工作环境对应关系
CD（Continuous Delivery，持续交付）
通过自动化工具可以对不同构建物的底层部署机制进行屏蔽
从来没有遇到过这种部署方式
使用OS特定构建物的好处是，在做部署时不需要考虑底层使用的是什么技术
不可变服务
不用考虑OS的环境配置问题
需要注意：机器上的持久化数据也被保存到了其他地方
定制化镜像/容器部署方案
平台特定的构建物
不同环境的管理是一个问题
推荐的方案是：有一个专门的系统来提供配置管理=>配置中心
保证在CD流水线的构建物是同一个，而不是分TEST构建物和PRD构建物
服务配置
运维团队的工作量通常与所要管理的主机量成正比
成本降低
主机的监控复杂
主机故障所造成的影响很严重
服务的部署也会变得更复杂
不利于团队的自治性
单主机多服务
应用程序容器：java和.net的方式
带来了很多的主机管理问题，人工管理是不可取的，必须自动化管理
每个主机一个服务：推荐这种方式
服务与主机之间的映射
第6章-部署
《微服务设计》读书笔记（上）
0 条评论
回复 删除
下一页
