05 | 后微服务时代：跨越软件与硬件之间的界限
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
在“后微服务时代”中，软件与硬件之间的模糊界限以及容器化技术对分布式架构问题的影响成为了热门话题。随着容器化技术的发展，特别是Kubernetes的胜利，软件与硬件的边界开始变得模糊，基础设施的虚拟化解决了分布式架构问题，使得应用代码与基础设施软硬一体，合力应对问题成为可能。这标志着“后微服务时代”或“云原生时代”的到来，基础设施的虚拟化为软件架构发展开启了新纪元。然而，作者也指出Kubernetes并未完美解决全部分布式问题，需要引入“服务网格”的“边车代理模式”来解决某些边缘问题。服务网格在2018年才开始兴起，但仍然是一个新潮的概念，其发展仍未完全成熟。作者认为，未来几年，Kubernetes将成为服务器端标准的运行环境，服务网格将成为微服务之间通讯交互的主流模式，将把技术问题隔离于应用软件之外，使得微服务只需考虑业务本身的逻辑。总的来说，文章深入浅出地探讨了软件与硬件界限的模糊、基础设施的虚拟化、云原生时代的到来以及服务网格的发展对分布式架构问题的影响。这为读者提供了对当前技术发展趋势的深刻理解。
请先领取课程
全部留言(37)
- 最新
- 精选
J.Smile感谢老师，连续看了几篇，把架构模式的发展历程了解的一下子就贯穿起来了。都说技术需要有前瞻性，我想这就是最好的指路明灯了。希望老师可以提供一些相关的书籍给予参考。作者回复: 这方面我没有看到特别好的书籍。所以产生了自己写一本的想法。
2020-11-30260
zhanyd软件架构的发展方向，是慢慢得把与业务无关的技术问题，从软件的层面剥离出来，在硬件的基础设施之内就被悄悄解决掉，让开发人员只专注于业务，真正“围绕业务能力构建”团队与产品。 把复杂的问题交给计算机硬件解决，使得开发人员只用关注业务，让开发越来越简单，同时能够调用的计算机资源越来越强大。 这也符合奥卡姆剃刀原则：“如无必要，勿增实体“。 如果问题能让计算机自动解决，就不要麻烦人类。：）作者回复: 完全同意
2020-11-28352
李皮皮皮皮皮看了今天的文章，边车模式我差不多理解了。有点疑惑的是这种流量劫持，并且需要做特征分析和熔断逻辑的处理，相对来说，性能是不是会下降很多。原本只用2个实例就能满足需求，现在必须用3个实例？作者回复: 等后面更新到服务网格的课程时（基本是最后几节课了），会讲解边车代理的网络通讯模式。 如果只是单纯转发，其实sidecar的性能损失不会很大，因为sidecar与服务是基于回环地址通讯的，且在对网络性能极端敏感的场合甚至可以基于unix domain socket通讯，绕过网络栈。 sidecar的性能损失主要取决于要对经过的流量做多少工作，在sidecar上对流量做特征路由、认证、授权、观测等事情，自然会损失响应的性能。但是用程序手段来做这些事情也照样要耗费性能的。
2020-11-2815
good boby给你举个例子，微服务 A 调用了微服务 B 中发布的两个服务，我们称之为 B1 和 B2，假设 B1 表现正常，但 B2 出现了持续的 500 错，那在达到一定的阈值之后，我们就应该对 B2 进行熔断，以避免产生雪崩效应。如果我们仅在基础设施的层面来做处理，这就会遇到一个两难问题，也就是切断 A 到 B 的网络通路，会影响到 B1 的正常调用，而不切断的话则会持续受到 B2 的错误影响。 大神您好！非常感谢您的微服务架构和k8s能联系起来，也解决了我的很多疑惑。但以上的例子个人觉得存在一些问题，k8s中配置liveness和readiness对容器进行健康检测，可以由k8s决定容器是否停用、移除和重新部署。当探针检测服务B的B1或B2出现异常，通过容器停用、移除或重启可以解决雪崩问题作者回复: kubernetes的探针并不改善容器编排系统对服务粒度管理只能到pod级别的问题，试想如果B1正常，B2出错，探针只能通知k8s重启整个pod，如果尝试重启并超过阈值后，B2仍是出错，那整个pod都处于fail状态，B1即本身使正常，也不再能够提供服务了。 要在基础设施层面解决这个问题，需要引入类似于Istio的VirtualService这样的CRD才能比较妥善地处理。
2021-02-1749
arctec今天的课程，站在更加独立的角度和视野，讲透了微服务的来生与未来，困扰我的一扇窗户打开了，感谢周老师的分享，期待后续课程更精彩！作者回复: 感谢认可
2020-11-277
Frank老师是否可以加点参考资料，对于刚入门的小白，有些概念不是很好理解。自己去找资料吧，又担心找到的是水货。作者回复: 好，原文中其实有很多名词我都加入了维基百科的链接，后面的课程我今年加多加点连接。
2020-11-276- Helios服务网格就是做到了治理的去中心化，比如老师上面提到的服务B的负载均衡到B1和B2如果是通过代理去转发的话我们控制不了，我们可以把后端地址都请求回来自己去决定，对于故障率高的节点可以采取熔断策略。 我觉得当前云原生这个概念还是有点虚，怎么说都对怎么说都不对，这可能就是变革产生的必经之路吧，所有的正确的思想汇聚到一起才能产生火花。 以后的架构可能更偏向能力化，我能做一个项目更加关注自己业务，其他的能力用厂商的就行，就像现在的无服务一样，我不用管我服务跑外哪，咋跑的。 想听听老师云原生的看法和对这种架构有什么缺点的剖析
作者回复: 云原生其实是很具体的，只是由于宣传等原因，各种场合都往上蹭热点，以至于目前有点混乱。 我认为云原生的没有什么缺点，但是有很高的要求。具体要说起来很复杂，你可以参考一下我这篇文章：https://icyfenix.cn/methodology/forward-msa/prerequest.html
2021-01-281 
snailshen老师整理的真好，从更高的高度看微服务架构和发展，虽然这些都接触过，但是由于工作主要不是负责这部分，没有仔细考虑微服务和容器技术之间的发展历程和联系，经过老师的讲解豁然开朗的感觉，多谢老师分享！！！作者回复: 感谢认可
2020-11-301
福杯满溢上帝的归上帝，凯撒的归凯撒。老师您是基督徒吗？作者回复: 额，并不是基督徒。 这是一句谚语而已。
2021-04-112
刘智恒微服务架构中硬件构成的基础设施需要灵活性。指的是服务发现和负载均衡这样的基础设施本身也存在伸缩扩容的需求吗？这一部分理解的不是特别透彻。作者回复: 有的。不过一次网络请求到应答的流程，至少会经过一个单点。过两个星期，会进入“透明多级分流系统”部分，讨论这方面的话题。
2020-11-27