转载

微服务架构-文章阅读整理01(3.19)

图片来源： https://www.ctolib.com/topics-112196.html

这篇作为我阅读知乎一个微服务专栏文章的笔记整理，方便后续阅读。

https://zhuanlan.zhihu.com/httpshop

这篇文章仅仅做为自己的一些笔记整理，对于文章原文里面提到的内容都尽量不在这篇文章进行重复论述。当然阅读感觉很多内容，在自己博客微服务相关文章中也都有过谈及，再次也是对相关点的进一步总结。

微服务架构下的一致性解决方案

在这点上最靠谱的还是基于消息中间件的BASE最终一致性人工补偿。对于两阶段提交而言不建议采用，带来的同步阻塞问题，包括网络异常下引起的数据不一致性短期很难真正解决。

其次，如果上层一个或多个微服务模块使用的是同底层数据库，我们仍然强烈建议将多个服务调用的分布式事务问题，转换为单个服务调用的单事务问题，毕竟同一个数据库的数据库级别事务控制是最保险的。即仅在出现了跨数据库的情况下，我们才启用基于服务调用下的分布式事务。

在微服务中进行日志跟踪的理论基础

这个在我们前面的博客文章也谈到过服务链监控的实现，其核心仍然是如何形成跟踪树，而Trace Tree的形成最核心的是两个内容，一个就是每一次接口服务调用都应该生产调用实例，其次就是服务调用实例间能够通过调用实例ID，父实例ID形成勾稽关系，形成跟踪树。这也是SPAN形成的理论基础。

简单来说几个关键点为下

1. 为整个服务链调用生产独立的调用链标识，该标识一直按相同值从根节点朝下传递。

2. A在消费B服务的时候，首先生成调用标识，同时将该标识做为父标识传递到B实例中。以此类推传递。

对于以上两点，我们都可以不在服务消费和调用的实际接口输入和输出中实现，而采用类似AOP的拦截截止进行拦截或埋点处理。那么这种服务链监控解决方案对实际接口服务调用侵入最小。

熔断器

对于熔断器，实际上我们要考虑两个方面，首先是基于什么来熔断，在这里再次总结实际上包括两个方面，一个是基于资源负荷，其中包括了CPU，内存和网络响应的资源负荷；其次是基于错误和异常大并发调用次数。基于这两个指标或指标组合来进行熔断即可。

其次是熔断的范围问题，对于当前微服务网关的熔断往往是对整个服务进行熔断，而实际上我们需要的是到消费方系统服务级别的熔断。

在这篇文章里面提到了，熔断器进行了熔断处理后，往往是经过一个预先定义的间隔时间后转为半打开状态，再服务能够调用成功后再进行全打开状态。这个思路是可以参考的。而在前面我们将服务流控的时候，也谈到需要设置一个间隔时间，在间隔时间后可以对流控策略进行解除。

如何设计高可用的微服务架构

如果保留Rest接口服务的实时调用模式，注意是整个微服务架构下耦合性更强，更加容易因为依赖的服务组件不可用而导致的整体业务功能异常。这个比传统集成架构下数据落地模式下更加容易异常。

除了硬件和中间件基础设施资源的高可用外，对于软件层面有哪些高可用。这里面有个重要的概念就是服务降级而不是服务完全不可用的。那么有哪些场景的服务降级呢？比如以下：

1. 只能够查询和浏览，但是不能够新增和更新数据

2. 只能够查看文字内容，但是不能查看到详细的图片信息

3. 只能够看到缓存的内容，无法看到最新的数据信息

4. 消息能够接收，但是无法实时得到反馈信息，需要后续等待后异步获取反馈

通过以上描述，我们可以看到，对于软件高可用层面的重点，仍然是缓存，本地化存储，消息中间件，读写分离等关键技术的实现和应用。

如何有效提升微服务架构的落地能力

这篇文章里面主要还是谈了DevOps在协助微服务架构落地所起的作用，而DevOps本身核心又在持续集成理论，配置管理等基础软件工程内容，容器化PaaS等平台层内容。而实际上微服务架构的落地，更加需要的是一个既懂业务又懂技术的架构师，这个架构师相当关键，即要做好微服务模块的划分和关键接口服务识别定义，又要做好微服务开发框架，基础的类似DevOps支撑平台的搭建。

微服务架构的落地首先是个业务问题和组织团队管理问题，其次才是技术平台和技术选用问题。

微服务场景面试问题可参考： https://zhuanlan.zhihu.com/p/59046576

DevOps架构下如何进行微服务性能测试

对于微服务架构下的性能测试，实际上在我博客上确实还没有专门的文章谈这块的内容。在这里先简单说明下，后续需要专门写文章来谈这块的内容。

即微服务架构下的性能测试，除了常规的接口服务性能测试的内容外，还需要重点关心的就是需要测试和验证到服务限流，服务断流和熔断场景。同时需要验证到在服务并发量增加情况下，对底层容器化平台的资源动态自动扩展场景。

当然还需要进一步验证是大数据量调用，大并发调用，长服务链服务调用，多服务组合调用等不同的场景下服务的响应情况，包括是否会出现类似的服务雪崩，整个集群的内存溢出等情况。

原文 http://blog.sina.com.cn/s/blog_493a84550102yp8z.html

正文到此结束