微服务进阶之路 容器落地避坑指南
|
第一点注意：新增功能点不能再在原有单体应用基础上开发，而是需要按照微服务方式开发，但由于这个微服务是隶属于原来单体应用的一部分功能，所以通常情况需要访问单体应用的数据，这个时候需要通过API的方式访问，以防止二者之间发生紧耦合。对于单体部分来说，无论是采用 Facade，还是 Adapter 或 Translator 模式提供 API，都是为新增的微服务模块提供松耦合的访问方式。 第二点注意：对于已有的单体部分也可以逐步微服务化，可选择经常变化、需要快速迭代满足用户需求的部分着手进行改造。经过几轮改造后要么整体替换掉原单体应用，要么剩下的是稳定不变的单体部分，周围就都是改造过的微服务混合架构了。 第三阶段收放自如——Service Mesh Service mesh 是微服务架构的一部分，它本质上是一个分布式计算中间件，通过拦截流量和安置策略来管理和优化服务之间的通信，使得服务变得更加健壮和安全。通常会提供微服务之间认证、鉴权、加密、服务发现、请求路由、负载均衡、服务自愈等功能。 部署微服务应用，Service mesh 是必不可少的部分。这是因为微服务应用是一个分布式的应用，因此相对于单体应用来说在稳定性、可管理性等方面都有很大难度，需要有 service mesh来管理帮助服务变得更加健壮和安全。 因此，Service mesh 选型也是比较重要的，经常听到有人纠结是选择 Istio 还是 Spring Cloud 等。我们认为 Istio 是 service mesh 的发展方向，从架构来说，它解耦了控制平面和数据平面，使得开发者可以专注于应用业务逻辑的开发，而复杂的分布式应用服务之间的通信交给 service mesh 来控制。Spring Cloud 在架构设计理念上是落后的，试想一下，开发者在开发微服务的时候还要思考如何在代码中实现熔断、灰度发布、负载均衡等问题，负担是非常重的。更重要的是 Spring Cloud 类型的 service mesh 只支持 Java 语言，完全违背微服务可以任选语言开发的主张，而且有 vendor lock-in 嫌疑。 Istio 身上鲜明的标签很多：天然适合 Kubernetes 平台，不侵入代码，无语言绑定，但不得不承认，Istio 还在发展过程当中，目前也有一些问题亟待解决： •性能依然不够理想。基于 Istio 实现的微服务，由于虚拟化、转发等因素造成的性能损耗依然过大，不过积极的方面是我们看到一方面这是社区持续改进的重点，另一方面我们看到大家在做一些有效的尝试，比如通过 cilium 做 service mesh 的 proxy，提升性能； 治理平台，但这又会造成一种和社区主分支不一致的问题，为将来能否和社区保持一致带来些许担心，是否会走上厂商绑定的老路还需要观察。值得一提的是，在2018年上海 KubeCon 大会上，Google 的开发者讲述了在美国三家公司成功将 Istio 用于生产的案例，相信类似的事情会发生的越来越多，也期待今年上海的 KubeCon 能看到更多来自 Istio 的分享。 虽然 Istio 存在上述问题，但我们更应看到其社区正在飞速增长，就好比一两年前 k8s、docker swarm 和 Mesos 之争一样，那个时候 k8s 强大的生态活跃度为它最终胜利打下了良好的基础，我们认为 Istio 就是在 service mesh 领域的 k8s，未来很有可能会赢得这个领域的主导地位。当一个应用的微服务越来越多的时候，service mesh 变得非常重要，而且目光看得更远一些，随着 FaaS 步入业务开发者的视野，大家越来越享受这种便捷、灵活的开发方式，这意味着以服务视角的开发模式会越来越流行，因此 service mesh 框架会变得越来越重要。 综上所述，通过 Istio 构建微服务治理屏幕，学习曲线起点比较高，运维也非常麻烦，运维人员关注的是功能的输出，比如熔断、限流、灰度发布等，但 Istio 要求他们先要部署组件，编辑 yaml，了解各种抽象的参数，这就好比在看 3D 电影前，让观众自己先要组装 3D 眼镜一样。因此，微服务进阶之路道阻且长，企业需要一个平台级商业产品，可以从业务视角来管理微服务的可视化工具或者平台，降低用户的学习和运维成本，提高用户的业务价值输出能力，帮助用户重塑数字化时代核心竞争力。
点赞 0 （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
