学校风采网站建设需求,广告平台推广渠道,广州住房和建设局网站,合肥室内设计公司有哪些摘要#xff1a;微服务设计应当是面向服务、适配团队、循序渐进的设计。
目录
开篇引言
微服务
什么样的服务是健康的服务
什么是微服务
面向服务的架构
微服务较传统单体架构多的行为
微服务行为带来的问题
微服务解决的问题 开篇引言
在之前的工作中#xff0c;有…摘要微服务设计应当是面向服务、适配团队、循序渐进的设计。
目录
开篇引言
微服务
什么样的服务是健康的服务
什么是微服务
面向服务的架构
微服务较传统单体架构多的行为
微服务行为带来的问题
微服务解决的问题 开篇引言
在之前的工作中有接触过一些微服务的设计方法例如按照业务职责划分、设计微服务时该考虑的特性……
享受过微服务带来的好处如快速修改服务、简化部署。也应对过微服务带来的挑战追踪一个问题跨越数十个服务等。
也了解过一些微服务设计“哲学”——什么“不追求最佳实践就是最佳实践”、“适合团队的微服务才是最好的微服务”等……零零散散说出来也结结巴巴。
那么该怎么成体系更深入的了解微服务呢
从《微服务设计》这本书开始吧。 文章按照自己的理解进行了内容补充和编排《微服务设计》阅读起来会更轻松文章更适合当做综合性笔记用于检索。 微服务
什么样的服务是健康的服务
一个健康的服务应具备功能正确、性能高效、可用性高、可维护性强、健壮抗压、协作顺畅。它通过技术如容错、监控和设计如自洽、单一职责实现既满足业务需求又能在复杂环境中稳定运行。健康状态需通过指标量化并持续优化。
服务最开始是单体服务随时间演化代码库变得臃肿庞大。
所有功能代码耦合在一起。
此时服务开始变得不健康会有高耦合、低拓展性、可用性差、维护困哪、开发效率低、健壮性不足的等问题。且所有功能耦合在一起缺乏隔离和灵活性。
微服务架构正是针对这些问题提出的改进方案。
一些指标定义如下
1. 功能性Functional Health 正确性服务按预期完成业务功能无逻辑错误。 例子订单服务能准确创建订单并返回结果。 一致性数据和状态符合业务规则。 例子支付成功后库存同步扣减。 2. 性能Performance Health 低延迟响应时间短满足用户体验通常200ms。 例子用户查询订单状态不超过100ms。 高吞吐能处理预期并发量。 例子支持每秒1000次请求。 资源利用合理CPU、内存、I/O不过载。 例子内存占用稳定在50%以下。 3. 可用性Availability Health 高可用服务 uptime 高如99.9%宕机时间少。 例子年宕机不超过8小时。 容错单点故障不影响整体功能。 例子依赖服务超时触发熔断返回默认值。 自愈能自动恢复如重启、重试。 例子Kubernetes检测Pod崩溃并重启。 4. 可维护性Maintainability Health 清晰边界职责单一接口明确。 例子支付服务只处理支付不混杂订单逻辑。 可观测提供日志、指标、追踪便于诊断。 例子集成Prometheus监控请求延迟。 易扩展代码和架构支持快速迭代。 例子新增支付方式只需改支付服务。 5. 健壮性Robustness Health 异常处理能优雅应对错误不崩溃。 例子输入非法参数时返回400而非500。 流量控制防过载如限流、降级。 例子每秒超1000请求时限流。 安全性防止攻击如SQL注入、DDoS。 例子使用OAuth认证。 6. 协作性Collaboration Health 接口稳定API契约不随意变更。 例子/orders接口保持向下兼容。 通信高效与其他服务协同顺畅。 例子异步事件通过Kafka可靠传递。 数据自治不依赖其他服务的数据源。 例子自带订单数据库。 健康服务的量化指标 SLA服务级别协议 可用性99.9%。 响应时间P95 200ms。 错误率低于0.1%。 资源使用率CPU70%内存80%。 告警恢复时间MTTR平均修复时间30分钟。 什么是微服务
微服务就是协同工作的小而自洽的服务。
定义
“微服务的协作”——是微服务设计中的重要一环需要考虑因为微服务带来的“微服务通信”、“微服务监控”、“微服务安全”等问题。
“小”——“微服务该多小”的设计是一个很考验领域划分能力的事情但是据实际工作经验来看这更多的跟团队架构相关。“组织架构很大程度上决定了软件架构”。
“自洽”——生命周期独立开发、测试、部署、升级独立不受其他服务牵制功能独立数据自洽有自己的数据存储。
面向服务的架构
从个人的经验来看生产中中小型企业很难做到让所有服务都处于健康的状态。多数企业也不会以技术位驱动进行产品或项目的开发。
从面向服务的角度来说拥有微服务带来的好处的同时也拥有了微服务带来的问题如通信消耗、监控、日志等。
需要铭记的是系统架构的演变并非一蹴而就而是一个循序渐进的过程。不要期待一步到位逐步优化和调整才是正道。
微服务较传统单体架构多的行为
服务拆分将功能分解为多个独立服务。
分布式部署每个服务单独运行于不同进程或节点。
接口通信服务间通过API如REST、gRPC或消息队列如Kafka交互。
独立数据存储每个服务拥有自己的数据库。
独立生命周期服务单独开发、测试、部署。
动态伸缩按需调整单个服务的实例数。
事件驱动异步通信和事件订阅如支付完成通知订单。
微服务行为带来的问题
复杂度增加管理多个服务、通信和部署更复杂。
网络开销服务间调用引入延迟和带宽消耗。
数据一致性挑战分布式数据难保持强一致性需依赖最终一致性。
故障排查难问题跨服务传播需分布式追踪如Zipkin。
运维负担监控、日志、容器管理如Kubernetes成本高。
接口不稳定服务间契约变更可能导致兼容性问题。
资源分散多服务运行可能浪费资源。
微服务解决的问题
耦合过高单体模块紧耦合微服务解耦为独立单元。
扩展受限单体全量伸缩微服务按需扩容。
部署缓慢单体全量部署耗时微服务独立快速发布。
单点故障单体崩溃影响全局微服务隔离故障。
开发效率低单体多人冲突微服务团队自治。
技术僵化单体技术栈单一微服务支持多样化。
性能瓶颈单体资源竞争微服务分散负载。
总体而言微服务的设计旨在打造一种低耦合、高内聚、具备容错能力、可扩展性强且适应敏捷开发的架构模式。它带来了“技术异构性”、“弹性伸缩”、“灵活扩展”、“简化部署”、“与组织结构对齐”、“可组合性”以及“优化可替代性”等显著优势。
