微服务设计原则

微服务

SOA:

SOA（Service-Oriented Architecture，面向服务的架构）是一种软件架构风格，它通过将应用程序的功能分解为独立的、可重用的服务来提高软件系统的灵活性、可扩展性和可维护性。以下是关于SOA架构的详细解释：

1. 核心概念：在SOA架构中，服务是核心构建块。这些服务是高度自治的单元，通过提供自我描述和自管理的接口来与其他服务进行通信。每个服务都完成一个特定的业务功能，并可以独立于其他服务进行开发、实施、测试和维护。
2. 主要特征：
   独立的功能实体：SOA架构强调服务的自我管理和恢复能力。常见的技术，如事务处理、消息队列、冗余部署和集群系统，在SOA中都起到至关重要的作用。
   大数据量低频率访问：SOA系统采用大数据量的方式一次性进行信息交换。
   基于文本的消息传递：SOA系统必须采用基于文本而非二进制的消息传递方式。这使得数据处理端可以只选择性地处理自己理解的那部分数据，而忽略其他的数据，从而实现非常理想的兼容性。
3. 应用原则：
   开闭原则：强调用抽象构建框架，用实现扩展细节。
   依赖倒置原则：高层模块不应该依赖底层模块，二者都应依赖其抽象。这有助于降低类与类之间的耦合。
   单一职责原则：一个类/方法只做一件事。
   接口隔离原则：使用多个专门的接口，而不是全部依赖于总接口。客户端不应该依赖它不需要的接口。
   迪米特法则：一个对象应该对其他对象保持最少的了解。
   实际应用：在实际应用中，SOA架构可以通过定义良好的接口和契约将应用程序的不同功能单元（称为服务）联系起来。例如，服务A可以调用服务B的REST API来实现某种功能，这仅涉及语法区别。
   总的来说，SOA架构是一种灵活的、可扩展的和可维护的软件架构风格，它通过将应用程序的功能分解为独立的、可重用的服务来提高系统的整体性能。

Microservices are the first post DevOps revolution architecture.
微服务是第一个支持 DevOps 的架构！

名称	服务化架构	非服务化架构
服务独立性	服务可独立发布、安装、运行、扩容，有独立的 SLA	只支持产品整体打包，无法支持单个服务发布、安装、运行及扩容
接口是服务与外界联系的唯一方式
接口是服务与外界联系的唯一方式	除接口之外的资源，都应该由服务自身提供，服务提供者不能依赖于服务消费者。	部件A直接依赖于部件B的内部实现，例如直接访问部件B的数据库表
服务调用方式	服务的调用只能通过协议接口，建议采用REST方式	使用直接链结程序、直接读取其他团队的数据库、使用编程语言的函数调用机制、使用进程间通信、使用共享内存模式、使用别人模块的后门，以上任何一种调用方式都不是服务化架构；
服务可以在运行期复用	可在运行期直接部署服务，通过接口调用来实现复用。	只能通过源代码复用；只能通过在产品中重新编译、链接来复用；只能通过系统停机，将服务重新打包来复用
服务间无启动顺序依赖	服务之间没有启动顺序关系；即所依赖的服务未启动时，本服务可以启动起来但不工作	服务必须按依赖关系顺序启动

*** 微服务SLA（Service-Level Agreement）是指服务等级协议

在微服务架构中起着重要作用。SLA是服务提供者与用户之间关于提供的服务水平的正式协议，它描述了服务的各项具体细则，如服务的性能水平、响应时间等。SLA的主要目的是为双方提供一个明确的、可以衡量的服务标准，这些标准旨在保障用户利益，避免因为服务水平下降而导致的不必要纠纷。
在微服务架构中，每个服务都是一个独立的单元，具有自己的SLA。通过设定明确的SLA，可以确保每个服务都达到预定的性能、可用性和可靠性标准。当服务出现故障或性能下降时，可以根据SLA进行故障隔离、使用替代服务或提供柔性服务，以保证整个系统的稳定性和可靠性。
此外，SLA还可以用于配置SLA升级、监控SLA履行情况等，以更好地管理微服务架构中的服务质量和性能。通过定期监控SLA的履行情况，可以及时发现潜在问题并进行处理，从而提高整个系统的稳定性和可靠性。
总之，微服务SLA在微服务架构中起着至关重要的作用，它有助于确保每个服务都达到预定的性能、可用性和可靠性标准，从而提高整个系统的稳定性和可靠性。

微服务的无状态性：

微服务无状态设计原则是指微服务要尽量做到无状态，这样可以实现横向扩展。具体来说，无状态服务是指不保存服务之间的会话或上下文信息，每个服务请求的处理过程都不依赖于之前请求的状态，每次请求都是完全独立的。

在微服务架构中，无状态服务具有以下优点：

可扩展性：由于无状态服务不需要维护状态信息，因此它们可以轻松地水平扩展，以应对高流量和负载情况。
高可用性：无状态服务可以通过多个副本来提高可用性，并且它们可以在任何时间点部署或删除，而不会影响应用程序的可用性。
简单性：由于无状态服务不需要维护状态信息，因此它们通常比有状态服务更简单、更容易维护。
在微服务中，无状态服务的实现通常需要将状态数据迁移到外部的数据库或缓存系统中，而不是保存在服务实例内存中。这样，即使服务实例宕机或重启，也不会丢失用户会话数据，客户端可以透明地切换到其他实例继续服务。

然而，无状态服务也有一些缺点，如需要额外的机制（如token、JWT等）来管理用户会话或跨服务的事务一致性，以及每次请求都需要携带足够的上下文信息，可能会增加网络开销。

总的来说，微服务无状态设计原则是一种重要的设计思想，可以帮助开发人员构建更加可扩展、高可用和简单的微服务架构

参考 亚马逊 微服务平台设计

升级：

应用先下线，升级完再上线
数据库从库下线，更新，再上线，主库下线后升主
redis 用做缓存， sql 做持久化

应用服务约束：
服务无状态化及多实例部署
数据服务热冗余
接口及数据库向后兼容

数据库倒换：
基于分布式协调锁技术的主库选择 与 主从倒换
数据库日志增量复制
支持主从数据同步

灰度发布：
按路由：老的是V1, 新的V2, 符合策略的用户路由到新的V2上面
负载均衡策略注入
版本分区部署

分层冗余：

接入层：
浮动 IP 保证高可用
ER 外部访问路由,IR 内部访问

应用层：
无状态改造

数据层：
主从
基于 Binlog 方式实现主从复制

微服务设计原则&CheckList

原则:

原则1：服务自治
1.1 服务独立交付
1.2 服务并行安装
1.3 服务并行启动/停止
1.4 提供完整功能
1.5 服务数据库去中心化
1.6 通过配置方式定制服务能力
1.7 定义服务SLA（Service Level Agreement）
原则2：服务无状态
2.1 数据不写入本地文件系统
2.2 HTTP会话数据共享
2.3 支持多实例集群部署
2.4 部署、升级过程可重入
2.5 定时器外置到Cron服务中
原则3：以接口方式提供服务能力
3.1 接口是服务与外界联系的唯一方式
3.2 以RESTful风格定义服务接口
3.3 提供粗粒度的原子服务接口
3.4 服务接口自说明
3.5 接口语言无关
3.6 提供简化调用的Client库
原则4：服务前后向兼容
4.1 服务接口后向兼容
4.2 服务数据模型前向兼容
原则5：分层依赖
5.1 服务不能循环依赖
5.2 原子服务不能依赖于组合服务
5.3 高可用性服务不能依赖于低可用性服务

类别 编号 检查项目 级别
服务自治 服务命名符合《服务命名规范》要求 MUST
有独立的代码仓库，根目录名称与服务名相同 MUST
代码目录符合《代码目录规范》要求 MUST
在CI（Jenkins）上有独立的构建工程，工程名称与服务名相同 MUST
发布版本号符合《服务版本号规则》要求 MUST
发布件目录结构符合《服务包目录》要求 MUST
能被单独安装，安装过程不依赖于其他服务必须安装 MUST
能被单独启停，启动过程不依赖于其他服务必须运行 MUST
禁止与其他服务共用数据库 MUST
服务业务功能完整，粒度合适（2-Pizza团队端到端负责） MUST

无状态 服务的初始化/升级脚本只能修改服务部署目录中的文件，初始化/升级脚本具备幂等性（多次调用的结果一致） MUST
支持多实例部署，实例可部署到不同的节点 MUST
服务集群在线弹性伸缩，不影响业务运行 SUGGEST
业务处理能力线性扩展，增加集群实例数可同比增加业务处理能力 SUGGEST
提供异地容灾能力 SUGGEST
提供异地双活/多活能力 SUGGEST
随机杀死服务集群中的某个实例，服务业务功能不受影响（通过服务集群可靠性测试工具测试） MUST

接口方式提供服务 对外提供REST接口，REST接口设计符合《REST API设计规范》 MUST
服务接口不区分内外部，所有接口都提供对应的接口说明文档，都可以被服务消费者调用 MUST
服务接口的调用有访问控制和流量控制 SUGGEST
提供明确的SLASLA（Service Level Agreement）指标定义（服务整体、关键接口），SLA指标定义符合《服务SLA规范》

服务前后兼容 "服务接口后向兼容，接口只增、不删、不改，废弃的接口按计划回收（通过服务接口兼容性扫描
工具检查）" MUST
从新版本回滚到老版本后（数据存储不回滚），老版本的业务功能正常 MUST

分层依赖 禁止服务间的循环调用（服务依赖扫描工具检查） MUST
禁止依赖低于自身可靠性等级要求的服务 MUST
禁止调用Website类型服务接口（浏览器除外） SUGGEST

命名

Service: 提供Rest 服务接口，不提供Web界面，可依赖 Service 类型的服务

Agent: 代理，提供Rest 服务接口，不提供Web界面，通常要在所有节点部署

Website: 有人机交互页面，只能依赖 Service 类型的服务，无特殊原因不依赖数据库