《ASP.NET Core 微服务实战》-- 读书笔记（第12章）

第 12 章设计汇总

微服务开发并不是要学习 C#、Java 或者 Go 编程--而是要学习如何开发应用以适应并充分利用弹性伸缩环境的优势，它们对托管环境没有偏好，并能瞬间启停

换句话说，我们要学习如何开发云原生应用

识别并解决反模式

我们既然已经学习了所有的示例代码，就正好可以着手开发、运行并完善它们

此时，我想再来回顾其中一些思路和哲理，以便为决策过程提供更充分的信息

清理团队监控服务的示例

在这一示例中，我们从一个管理团队及团队成员的简单服务开始

后来扩展了服务的定义，向它添加了用于跟踪位置的后端服务

接着在第 6 章中，开发了一个解决方案

先由移动应用将团队成员的 GPS 坐标信息提交给位置报送服务

接着这一信息流经整个系统，最终产生关于接近事件的通知并发送到用户直接接触的某种界面

问题在于事件处理器和事实服务使用的其实是同一个数据存储

将数据库作为集成层一个常见的副作用在于：最终将有两个或更多服务依赖共同的数据库结构与方案才能正常工作

这意味着，我们将不能独立对基础数据存储进行变更，而这些服务的发布节奏最终将互相绑定在一起，而不能按照期望的方式独立地发布

为修正这一问题，我们可以重新设计架构

在新的设计中，事件处理器和事实服务并不使用相同的数据存储

事件处理器调用事实服务，让它完成写入当前位置的工作

在新的架构中，事实服务拥有事实缓存数据的唯一所有权

另一项优化是让事实服务维护其自有专用数据的同时，还维护一份外部缓存

继续辩论组合式微服务

组合式服务是依赖另一个服务的调用才能完成功能的服务

这种调用通常都是同步的，也就是需要阻塞原始调用，直到嵌套的一个或多个调用完成

在第 8 章中，请求产品详情的客户端，在目录服务发起向库存服务的同步调用以获取特定项的库存状态期间，只能等待

当这一做法在整个企业范围里大量运用，开始有客户报告超时和莫名其妙的服务端错误

这是因为在嵌套同步调用栈上的某个位置发生了失败，而下层的失败则会产生最终返回给客户端的层叠效应

使用断路器缓解风险

处理嵌套式同步调用的一种潜在方案是寻求一种后备机制，一种当调用链上任何位置出现失败时的统一处理方法

当后端服务出现失败时，为防止请求崩溃或者无限期等待而提供一种后备处理的做法通常称为实现了“断路器”模式

消除同步的组合模式

关于断路器和组合式服务最重要的决定并非是如何实现它们，而在于是否确实需要它们

就像我们并非永远都处在于一片乐土之中，我们也不可能总能得到理想中的微服务架构

不过，只要稍微花点时间，对问题和潜在的解决方案加以分析，找到排除常见障碍的思路，就可能避免服务组合

接下来，还要做什么

首先，也是最重要的一点就是“质疑一切”

本书的每一条建议和每一行代码都需要经过验证

本书只是一个起点，希望它能为你提供灵感，为你基于 C# 和 .NET Core 开发强大的、具有弹性伸缩能力和跨平台的微服务提供足够的技术支撑

.NET Core 需要更多的宣传和监督，以及更多人士在生产环境运用它，为完善和巩固它出谋划策，让它成为开发云原生微服务更具优势的平台