旅游

微服务进阶之路容器落地避坑指南

2019-05-15 03:17:35来源:励志吧0次阅读

来源:青云QingCloud

作者:周小四 青云QingCloud 应用及容器平台研发总监、于爽 KubeSphere容器平台产品经理

编者按:容器和容器编排系统仅仅是部署和运行的基础平台,开发人员需要关注更多的是部署在平台上的应用。容器时代,运用架构发生了巨大变化,如果要让应用在容器平台上发挥其的功效,我们就必须走上微服务道路。但是,容器落地的过程中路多坑更多,微服务进阶之路需要更多经验之谈。

微服务架构相对单体架构有很大的变化,也产生了一些新的设计模式,比如 sidecar,如何开发一个微服务运用是一件有很大挑战性的事情,我们经常会听到有人讨论如何划分微服务,多细的颗粒度才是微服务等问题。初学者经常会处于一个忐忑不安的状态,所以我们急需要知道如何才能走上正确的微服务道路,或者需要一些实践指点我们如何设计、开发一个微服务应用。

不骄不躁不跟风 知己知彼方可百战不殆

虽然现在已经进入到一个不谈微服务就落伍的时期,但作为 IT 从业者,我们一定要站在切身利益出发,多思考几个为什么,不要急于跟风。原因很简单,不管外面如何风吹雨打,只要你的房子足够结实、安全、舒服,那一般情况下就不需要拆除重建,所以在决定继续沿用单体架构还是转向微服务架构之前,我们一定要做两件事情:

件事,从外部了解两种架构各自的优劣:

可以看到,单体应用并不是一无是处。

第二件事,审视我们自己的业务:

上述单体架构列出的一些问题是不是已严重影响了我们的业务?

企业新的业务系统是否要满足快速迭代、弹性等需求?

团队内是不是有 DevOps 氛围?

企业内是否有足够的动力和技术储备去接触新的技术?

了解了单体运用和微服务应用的优劣特点,分析了企业自身的业务诉求和实际情况,终还是决定转型微服务架构,那么我们也要清楚这不是一朝一夕的事情,需要分阶段逐步推动。

蒙眼狂奔不可取 循序渐进方可顺利进阶

阶段试炼 开发新应用

对初次接触微服务的企业,选择新运用入手是正确的方式。

步可以选择 web-scale、无状态类型的新运用上手,比如基于 nginx 的站、文档等,这类应用非常简单且容易实现,而且能体验到微服务在容器平台上的各种功能。有了一定的经验之后,第二步就可以开发有状态类型的新应用,有状态服务的挑战就是数据管理。敲重点,跟以往单体应用的共享数据库不同,微服务运用中的每个服务独享自己的数据库,服务之间需要通过 API、事件或消息传递的方式来相互访问对方的数据,而不是通过直接访问对方数据库的方式。

换句话说,理想中的微服务是封装自己的数据,通过API暴露数据出去,从而避免数据耦合,这样每个微服务的数据格式发生变化也不影响其它微服务的数据调用。开发过和升级过大型企业单体应用的人对此会深有体会,一旦有人改变了数据库 schema,全部运用都有可能启动不起来,团队开发效力会大大降低。

微服务架构其实不尽善尽美,合适自己的方案才是王道。

不难理解,微服务数据是牺牲强一致性而通过终究一致性的方式来管理,这对数据的划分带来很大难度,比如不能再用 join 的方式访问不同服务之间的数据表,实际当中也比较难做到或者做起来很麻烦,现在也没有成熟且好用的库或框架提供微服务的数据管理,而且某些应用确切需要强一致性。而此时,我们不能通盘否定此类应用微服务化的可行性,应该适当折衷或妥协,采取 miniservice。

Miniservice 在开发与部署的独立性和敏捷性方面类似于微服务(microservice),但没有微服务那么强的束缚。通常情况下,一个 miniservcie 可以提供多个功能,这些功能之间可以共享数据库。这个时候千万不要畏惧混合架构,不要害怕自己的微服务应用是不是正统,think big,start small,move fast才是我们应该遵守的哲学。因此,一个企业运用里既有 microservice 也有 miniservice,甚至有单体部分(可以称之为 macroservice)都是可以接受的。

以一个电商平台举例,在整个场景里面,业务开发人员面对的主要压力来自前端频繁的变动,因为要应对频繁的促销、推行、降价等活动,所以面对消费者前端的业务需要快速迭代。消费者会不停的阅读商品,终产生交易的要求数量要远低于获得商品信息的要求数量,因此将前端业务无状态化,进行微服务拆分、解耦,便可以快速应对市场变化,灵活做出改变。

那是不是把整个平台都做到微服务级别会变得更好?答案是不确定,由于当微服务量级到达一定程度,由此产生的管理和运维压力是指数级增长的。而实际上,对于有些业务来讲也没有必要微服务化,比如很多电商平台都有 2B 的业务,其业务变化的频度和压力没有 2C 那末大,那以 macroservices 或者 miniservices 的方式去交付也是可以的。开发人员应当分析在整个运用架构体系中,哪些适合微服务化,哪些亟需微服务化。

实践出真知

在上面的电商案例中,我们提到了服务无状态化,之所以期望服务无状态化,是因为无状态应用可以做到快速的扩缩容,可以应对井喷流量,可以效率的利用计算资源。我们经常听到,以无状态为荣,以有状态为耻,说的就是对于一个服务要尽可能无状态化它,比如用户 session 管理,以前我们在业务逻辑模块进行管理,导致这些模块不能依照无状态方式任意伸缩。我们可以把这些 session 的管理抽取出来放到一个高可用或分布式的缓存中管理,业务模块通过调用API的方式去获得 session,这样就实现了这些模块的无状态化。

但这并不意味着所有服务都做到无状态才是的,开发者要细细思考自己的业务模型并进行服务拆分,不要为了无状态而无状态,由于总是会存在有状态服务的。

第二阶段进阶 改造遗留运用

如果我们经过认真思考后仍决定对遗留应用进行微服务化,比如需要新增功能、快速迭代现有功能等,那末遵循一些实践经验。明显,另起炉灶开发一套新的系统不太现实,失败的概率非常高。

点注意:新增功能点不能再在原有单体应用基础上开发,而是需要依照微服务方式开发,但由于这个微服务是隶属于原来单体应用的一部分功能,所以通常情况需要访问单体应用的数据,这个时候需要通过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,提升性能;

门坎高。Istio 虽然控制面做的很,但上手成本依然很高,很多企业用户还处在容器化改造阶段,以一种复杂面貌去呈现是很难很快融入企业 IT 架构中的;

落地实践少。虽然社区火热,被谈论的热度很高,但企业用户或在观望,或者在尝试,我们能看到的是有技术实力的互联公司将 Istio 中的某个组件拆解出来,或改造、或接入他们现有微服务治理平台,但这又会造成一种和社区主分支不一致的问题,为将来能否和社区保持一致带来些许担心,是不是会走上厂商绑定的老路还需要视察。值得一提的是,在2018年上海 KubeCon 大会上,Google 的开发者讲述了在美国3家公司成功将 Istio 用于生产的案例,相信类似的事情会产生的越来越多,也期待今年上海的 KubeCon 能看到更多来自 Istio 的分享。

虽然 Istio 存在上述问题,但我们更应看到其社区正在飞速增长,就好比一两年前 k8s、docker swarm 和 Mesos 之争一样,那个时候 k8s 强大的生态活跃度为它终究成功打下了良好的基础,我们认为 Istio 就是在 service mesh 领域的 k8s,未来很有可能会赢得这个领域的主导地位。当一个应用的微服务越来越多的时候,service mesh 变得非常重要,而且眼光看得更远一些,随着 FaaS 步入业务开发者的视野,大家越来越享受这种便捷、灵活的开发方式,这意味着以服务视角的开发模式会越来越流行,因此 service mesh 框架会变得越来越重要。

综上所述,通过 Istio 构建微服务治理屏幕,学习曲线起点比较高,运维也非常麻烦,运维人员关注的是功能的输出,比如熔断、限流、灰度发布等,但 Istio 要求他们先要部署组件, yaml,了解各种抽象的参数,这就好比在看 3D 电影前,让观众自己先要组装 3D 眼镜一样。因此,微服务进阶之路道阻且长,企业需要一个平台级商业产品,可以从业务视角来管理微服务的可视化工具或平台,降低用户的学习和运维成本,提高用户的业务价值输出能力,帮助用户重塑数字化时代核心竞争力。

大道至简 举重若轻诚邀您参加将于4月19日在北京北辰洲际酒店举办的KubeSphere 容器平台发布会,轻量级调度全栈云功能,助力企业快速步入云原生之旅,扫码报名,带你在数字化转型中一步!

月经量多怎么调理
月经量多注意什么
月经有血块怎么回事儿
分享到: