微服务设计的方法是什么

本文主要讲解“微服务设计的方法是什么”。本文的解释简单明了，易学易懂。接下来，请跟随边肖的思路，一起学习学习“微服务设计的方法是什么”！

一、微服务架构理论

1.六边形建筑

1)六边形架构，也称为端口和适配器架构风格；使用适配器与外部世界交互，外部世界通过应用层API与内部世界交互。

2)经典的分层架构更注重抽象的分离，各层职责划分清晰。在六边形架构中，使用“组件化”来避免耦合，每个业务单元尽可能最小化。这种方式用一个词概括，就是“扁平化”。

3)经典的分层架构分为四层，而六边形架构一般分为三层：域层、端口层和适配器层。

2.服务的规模

1)在某些场景下，认为每个微服务的开发工作量不应超过2周。

2)黄金法则是微服务的修改和部署不会影响其他服务。

3.微服务的优势

1)技术异质性

2)高容错，服务降级(隔板)。单个服务故障不会导致整个系统故障。

3)已经扩展。只需高负载扩展应用即可。

4)简化部署比部署单个大型应用程序更简单。

5)与组织结构相匹配，易于分配。

6)组合性和可重用性。

7)替代优化可以避免无法改造大型单一应用的痛苦。

4.OSGI

OSGi(开放服务网关倡议)支持模块热部署，方便模块管理。然而，它最终是基于jvm的。一个服务的失败仍然会导致整个jvm crush.osgi适合构建单个服务节点的内部应用。对于微服务架构，它在大多数场景下都不实用。随着java9之后JPMS的引入，OSGI的应用场景更加被挤压。

00-1010 1.原则

1)进化架构师应该从进化的角度来看待问题，而不是专注于具体的技术细节，追求完美。

2)分区架构师不应该过多关注服务内部的问题，而应该更多关注区域之间的问题。

3)战略目标的设定不是架构师的责任。

4)代码治理控制示例

5)评估技术债务。

6)异常管理

7)集中治理和团队建设

2.设计标准

1)监测健康监测应规范化，监测服务不应因具体服务而改变。

2)接口

A.a.API要与消费者解耦，选择技术无关的实现方式，容易升级，比如随意添加字段，不影响现有消费者。

B.REST API设计要基于“资源”，无状态，URL中没有动词，只有名词，并使用GET、POST、DELETE等操作资源。

GET:查询，POST:添加，PUT:更新，DELETE:删除

C.API应该有版本的概念。

D.使用令牌代替cookie进行身份验证。

在e.RFC标准中，大写和小写的URL是敏感的。虽然在实际使用中并不敏感，但是应该统一使用小写，并且应该使用-代替_作为字符串分隔符。搜索引擎认为字符'-'是多个关键词，IE浏览器不太支持' _ '。

F.速度限制

如果访问次数得不到控制，很可能会受到DDos的攻击。为RFC6585引入了HTTP状态代码429(请求太多)。

Github API使用的三个相关头：

X-RateLimit-Limit:允许用户每小时发送请求的最大值。

x-rate limit-剩余：当前时间窗口中剩余的可用请求数

当X-RateLimit-Rest:时间窗口重置时，此时可用的请求数将成为X-RateLimit-Limit的值。

G.使用HTTP头来处理缓存和并发

H.分页应该在大型结果集上执行。

一、避免多个服务共享一个数据库的情况。

3)注意架构的安全性，正确处理错误请求，使用断路器。

00-1010 1.高内聚、松耦合原理

2.使用领域工程和边界上下文来划分服务。

3.避免过早的服务分工

4.优先考虑地理位置和组织结构，按技术接缝划分不一定正确。

00-1010 1.选择

通常，合作可以更好地降低耦合度。

3.避免灾难性故障转移。例如，将导致使用者崩溃的消息，您应该设置最大重试次数，并及时将它们移动到死信队列中。

4.通过引用访问服务资源时，如调用邮件发送模块，发送往往会延迟，发送内容可能已被修改。正确的方法是只发送参考，然后在发送邮件时查询详细信息。

5.服务应该采用容错读取。

后置法

则，鲁棒性原则 每个模块都应该宽进严出，对自己发送的东西严格，对接收的东西容错。

五、分解单块系统

1.通过界限上下文，找出系统接缝，通过接缝拆分服务及数据库。 重构数据库的最佳实践是，先分离数据库，再拆分应用。

六、部署

1.CI(Continuous Integration,持续集成)
CD(Continuous Delivery,持续交付)
a.构建流水线，将构建分解为多个阶段，快速失败。
b.在项目初始阶段，所有服务可以放在一个构建里，当服务稳定后，应该每个微服务都有自己的构建。
c.定制化镜像，加速部署；将微服务本身也预安装在镜像中，将镜像作为构建物。
d.统一配置文件管理，开发专用部署系统。

七、测试

1.消费者驱动契约测试(Consumer-Driven Contract,CDC)
CDC可以有效避免变更破坏新服务的消费者。CDC会定义消费者的期望，这些期望会变成对生产者的测试代码。
2.部署后再测试
仅仅依靠部署之前的测试，不可能把缺陷率将为0。部署与上线是不同的阶段，可以通过蓝绿部署，部署两套系统，但只有一套系统接受真正的请求。 也可以采用金丝雀发布，将一小部分真正的流量引向新版本，进行验证。
3.平居故障修复时间MTTR胜过平均故障间隔时间MTBF
4.Scrum敏捷软件开发中，将自动化测试分为了单元测试、服务测试、用户界面测试三层。

八、监控

1.使用语义监控，我们可以在生产环境运行一些测试用例，当这些案例如果没有达到我们预期的值时，我们会认为生产环境的某个环境出问题了；如定时打开首页等。
2.通过关联标识，标记调用链，例如在HTTP首部追加标识。
3.建立标准化的日志，以标准格式记录日志，统一服务指标名称(响应时间、错误率、应用指标等)。

九、安全

1.身份验证和授权方式
1)SSO
2)SAML安全断言标记语言 基于XML/SOAP的开源标准数据格式
3)OpenID Connect协议 4)单点登录网关 使用网关验证身份与授权；认证通过后，网关将主体信息放在HTTP头上。
应该进行深度防御，不应完全依赖单点登陆网关。也可以在网关上终止HTTPS，进行入侵检测等。
单点登陆网关应该只负责粗粒度的授权，细粒度的授权应该在服务中实现。
2.服务间身份验证和授权
1)在边界内允许一切。
2)使用HTTPS基本身份验证
3)使用SAML或OpenID Connect
4)使用客户端证书
5)在HTTP之上使用HAMC
当使用HTTPS性能损耗较大，且不能缓存时，可以使用HMAC。
HMAC(Hash-based Message Authentication Code,基于HASH的消息码)，它使用对称密钥，将请求的主体和密钥一起，进行HASH处理。
服务器也进行hash就知道数据是否被篡改了，但不能防止数据泄露。在亚马逊S3中使用了该方式。
6)API密钥
7)SSL之上的流量不能被反向代理服务器缓存。HTTPS的CDN价格较高。
8)混淆代理人问题
成功通过认证的用户可能会伪装成其他用户，访问他人数据。
3.数据安全
使用加盐的密码hash
不应把敏感的数据写入日志
4.深度防御
防火墙/日志/入侵检测/网络隔离/操作系统
5.OWASP安全框架 安全威胁Top10

十、组织与系统设计的关系

1.康威定律
任何组织所交付的设计方案在结构上都与该组织的沟通结构保持一致。
反向康威定律
设计糟糕的系统有时迫使组织修改其结构，以适应系统。
2.组织耦合度
通常松耦合的组织开发的产品模块化更好，耦合度更低。
典型的紧耦合组织如商业产品公司，松耦合组织如开源社区。
3.组织与软件质量的关系
在windows vista的开发中发现，与组织结构相关联的指标和软件质量的相关度最高。而非代码复杂度等常见指标。
4.组织应对服务的整个生命周期负责
组织应对服务具有所有权，而非多个组织共享服务所有权。
在涉及多个组织的项目中，不共享服务所有权，会带来沟通问题。较为有效的解决方案是实行内部开源，互相开放代码与文档，像开源项目那样贡献与合并代码。
保证代码质量，与持续可维护性。
5.组织结构应该与界限上下文保持一致。
6.不同业务线间的服务应采用异步批处理方式，以便可以随时停机维护。

十一、规模化微服务

1.部署名词
1)蓝绿部署
同时部署两套冗余系统，实现不停机升级。涉及在途业务及数据迁移。
2)A/B测试
一部分用户用老系统/一部分用新系统 验证新系统可靠性。
3)灰度发布/金丝雀发布
在保持老版本可用的情况下，部署一套新系统，新系统有问题立即切换回老系统。
4)滚动发布
只有一套集群，无冗余，每次取出一部分，如20%的服务器升级，直到全部升级完成。
2.架构安全性措施
在出现故障时，应当能够恰当的功能降级，而非使整个系统下线。
要防止由于某一服务的故障导致级联大崩溃。
架构安全性措施：
超时/延迟带来的危害往往致命，要注意超时机制的使用。
断路器，下游出现问题时，及时断开，快速失败。
舱壁，隔离影响。
隔离，设计上允许下游离线，服务间相互隔离。
3.幂等
4.扩展
垂直扩展 更好的主机
拆分负载 拆分成不同服务
分散风险 分散部署
负载均衡 SSL往往会在负载均衡器前终止，为了防止信息泄露，可以尝试把负载均衡器与后端实例放在一个局域网内。
基于worker的系统 除了负载均衡，也可以通过消息队列来降低脆弱性，降低负载。
5.数据库扩展
读写分离 扩展缓存往往比读写分离更有效。
写扩展 数据分片，更好的主机，分片扩展困难，不能解决HA。
避免共享一个数据库基础设施 一个物理数据库建立多个schema。
尝试使用CQRS(命令查询职责分离模式) 将应用程序分为两部分：命令端和查询端。命令端处理程序创建，更新和删除请求，并在数据更改时发出事件。查询端负责查询。
6.缓存
1)客户端缓存/反向代理和CDN缓存/服务器端缓存(一级缓存、二级缓存)
2)HTTP缓存
a.cache-control TTL(Time To Live)指定缓存几秒
b.设定Expires头部 指定缓存到某一具体时间，如：新版本上线时间
c.设置Etag 在URL后增加随机字符串
3)必要时增加写缓存，先写缓存，再写入数据库。
4)使用弹性缓存 在下游出现故障时，使用缓存的数据，比停止服务好。
5)隐藏源服务 在缓存故障或大量失效时，要避雪崩。可以通过快速失败、数据库本地一级缓存等措施保护源服务。
6)应避免多级缓存，不要使用过长的缓存过期时间，在ISP和用户浏览器中的缓存是不受控的。
7)卫报使用了爬虫技术，爬取自己的网页，在系统故障时，有一个可使用的静态网页。
7.CAP定理
无法同时满足一致性Consistency、可用性Availability、分区容错性Partition
由于分布式系统必须要分区，所以往往权衡选择AP或CP。
可以在部分功能使用AP、另外一些功能使用CP。

十二、微服务原则

1.微服务理念

核心 自治的小服务
围绕业务概念建模
自动化的文化
隐藏内部实现细节
一切都去中心化
独立部署
隔离失败
高度可观察
2.问题
要熟悉业务领域，划分服务。
集群的部署/监控等问题。
不建议从0开发微服务，优先考虑单体服务。
不应使用数据集成。
微服务应面向业务建模，而非面向技术建模；应避免技术导向。

感谢各位的阅读，以上就是“微服务设计的方法是什么”的内容了，经过本文的学习后，相信大家对微服务设计的方法是什么这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是，小编将为大家推送更多相关知识点的文章，欢迎关注！