加载中…
个人资料
人月神话
人月神话 新浪个人认证
  • 博客等级:
  • 博客积分:0
  • 博客访问:4,073,151
  • 关注人气:5,901
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
正文 字体大小:

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

(2019-03-19 20:59:48)
标签:

微服务

杂谈

分类: IT咨询

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

知乎专栏地址为:
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架构下如何进行微服务性能测试

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

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

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

0

阅读 收藏 转载 喜欢 打印举报/Report
  

新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

新浪公司 版权所有