微服务架构的现状分析( 二 )


天下没有免费的午餐,谷歌此时已经联合 IBM 、Lyft 启动了 Istio 项目,开始着手第二代 Service Mesh 的布局 。就在Linkerd加入CNCF四个月后,Istio 发布了第一个 Release 版本,虽然 Bug 众多 。社区反响热烈,群众们纷纷表示欢迎并站队 。Linkerd 直接成了“过气网红” 。Istio 的使命是为谷歌K8S生态圈的延伸,建立其在微服务领域的头部位置 。
憧憬是美好的,从一开始 Istio 就是一个“早产儿”,数个版本都存在可用性不足的情况,除了一些头部公司很少有相关的落地案例,甚至一些公司也是处于研究阶段 。不过随着Istio 1.5的发布这一状况正在得到改善 。但是 Service Mesh 目前还属于微服务的金字塔,需要熟练运用容器技术以及出色的运维能力,学习曲线相对陡峭一些 。
4. 其它还有其它一些企业,也想在微服务领域有一席之地,比如 RedHat 推出了 Quarkus。Oracle 自己也搞了一个 Helidon 。

微服务架构的现状分析

文章插图
 
都有各自的一些卖点,但是似乎社区并不买帐 。但是它们都跟 Reactive Programming(反应式编程) 扯上了关系,这可能是另一种趋势 。微服务还在不停的向前推动,现在你不知道微服务都不好意思说你是搞后端的 。
然后回到现在的 TARS,现在的公司不搞个基金会弄个开源项目,都不好意思说你是技术公司 。TARS 同样走了一条自己的路,但是这条路目前我个人并不看好 。
5. 你真的需要微服务吗在开始实施微服务前你要考虑一些问题,而不是随大流 。这也是一些中小企业容易犯的错误 。
业务是否需要技术服务于业务是亘古不变的铁律 。微服务解决了你当前业务的什么问题,带来了什么问题你要清楚 。一共几万人的应用,日活区区几千人,你搞微服务?
团队是否准备好了微服务意味着将应用“复杂化了”,从单体应用分割到多个应用,从团队的技术素质、运维能力都是一种考验 。团队是否能够充分应对分布式带来的负面作用 。




推荐阅读