位置:编程技术网 > 研发管理 > 正文 >

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

2019年04月25日 01:47来源:未知手机版

d3201,河北搜才网石家庄,西数移动硬盘,中国时尚大典,3mxx,计算机网络技术介绍中华人民共和国,c3604bd,巴斯夫中国

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

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

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

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

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

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

单体微服务代码1. 代码量巨大,新人很难理解或上手

2. 代码黑洞,无人敢改

3. 各功能紧耦合,强依赖,难拆分

4. 语言栈相对单一,团队沟通相对容易,企业招聘技术人员相对容易1. 代码库分散,各个库代码体量相对较小

2. 要求开发人员必须有良好的代码注释和写文档的习惯,否则通过单一的服务很难理解其背后的业务含义

3. 要理解一个完整的业务联调,可能要跨多个服务模块、多个语言栈部署与测试相对比较容易在微服务数量较多时,需要做大量的服务间依赖顺序的适配和调整,运维成本高开发工具成熟,上手容易多样启动慢,因为代码经年累月,应用体量越来越大快,但要解决服务间依赖的问题弹性差强迭代慢、笨拙快、灵活扩展性差,功能模块间无明显界限强运维成本运维平台构造成熟,成本相对较低运维平台构造复杂,成本高团队协作效率低,很难规模化开发小团队,内部沟通方式灵活可靠性功能间紧耦合,互相影响,某一环节出问题会影响整个应用服务间松耦合,独立部署,可快速更新升级、回滚、扩展

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

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

上述单体架构列出的一些问题是否已经严重影响了我们的业务?企业新的业务系统是否要满足快速迭代、弹性等需求?团队内是否有 DevOps 氛围?企业内是否有足够的动力和技术储备去接触新的技术?

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

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

第一阶段试炼—— 开发新应用

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

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

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

本文地址:http://www.reviewcode.cn/yanfaguanli/45780.html 转载请注明出处!

今日热点资讯