微服务设计笔记

转载请注明出处 http://www.paraller.com 原文排版地址 点击获取更好阅读体验

这是一篇《微服务设计》的学习笔记，主要是自己提炼的一些知识点，书比较薄，建议看原版书理解相关概念。

简介

相关概念

• 背景：随着代码库越来越大，代码修改困难 、 模块之间界限模糊 、 相似代码过多。
• 内聚性 - 单一职责原则：相同原因而变化的东西放在一起，因不同原因变化的东西分离开来；微服务将这个理念应用到独立的服务上，根据业务的边界来确定服务的边界。
• 微服务是SOA的一种特定方法

特性：

• 一个微服务就是一个独立的实体，可以独立部署
• 服务之间通过网络进行通讯
• 服务彼此间可以独立的进行修改，服务的部署不应该引起消费方的变动
• 服务暴露过多，会造成和消费方的紧耦合

优点：

• 技术异构性： 尝试新技术，降低风险
• 系统中组件不可用，不会造成级联故障
• 扩展：对服务进行针对性的扩展
• 简化部署：特定代码部署，不影响系统整体，快速回滚
• 组织结构匹配： 不同的团队负责不同的服务
• 可组合性： 对不同的场景组合服务

分解技术

微服务

• 分布式系统的复杂性
• 部署、测试、监控的投入
• 类型分布式事务和CAP的考虑

共享库

对重复代码进行分包组织，工具类，重复业务代码类。缺点如下：- 无法使用异构技术- 每次更新，需要将相关的程序重新部署- 公共任务并且不属于业务代码，可以这样做，但如果涉及服务间的通讯，会成为耦合点

模块

Erlang的模块化能力惊人；难度比较大，很容易会和其他代码耦合在一起

微服务演化

需要注意细则

• 架构师类似城市规划师，专注在大方向上，有限情况参与到具体的开发，不关注每个区域内发生的事，更关注区域之间的事情（服务之间的交互）
• 未来的变化很难预见，对所有可能性进行预测，不如做一个允许变化的计划
• 系统设计方面的决定通常是取舍。
• 为了和更大的目标保持一致，制定一些具体的规则，称为原则
• 原则作为指导，约束是很难被改变的。显示指出两者，并定期回顾是否要修正。
• 编写文档是有用的，配上真实的代码范例
• 架构师提供一些温和的指导，让团队自行决定何时偿还债务，维护一个债务列表，并定期回顾
• 偏离原则：针对某个场景记录下来，当例外很多次出现，考虑修改原则
• 架构师和团队小组存在分歧，大部分情况要认同小组的决定。

要求的标准

• 建议确保所有的服务使用同样的方式报告健康状态 及 监控相关的数据，标准化，隐藏具体技术实现， 日志服务和监控服务一样，要集中化
• 使用统一的接口协议

如何建模服务

概念