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

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

——本文来自青云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 的开发者讲述了在美国三家公司成功将 Istio 用于生产的案例，相信相似的事情会发生的愈来愈多，也期待今年上海的 KubeCon 能看到更多来自 Istio 的分享。

虽然 Istio 存在上述问题，但咱们更应看到其社区正在飞速增加，就比如一两年前 k8s、docker swarm 和 Mesos 之争同样，那个时候 k8s 强大的生态活跃度为它最终胜利打下了良好的基础，咱们认为 Istio 就是在 service mesh 领域的 k8s，将来颇有可能会赢得这个领域的主导地位。

当一个应用的微服务愈来愈多的时候，service mesh 变得很是重要，并且目光看得更远一些，随着 FaaS 步入业务开发者的视野，你们愈来愈享受这种便捷、灵活的开发方式，这意味着以服务视角的开发模式会愈来愈流行，所以 service mesh 框架会变得愈来愈重要。

综上所述，经过 Istio 构建微服务治理屏幕，学习曲线起点比较高，运维也很是麻烦，运维人员关注的是功能的输出，好比熔断、限流、灰度发布等，但 Istio 要求他们先要部署组件，编辑 yaml，了解各类抽象的参数，这就比如在看 3D 电影前，让观众本身先要组装 3D 眼镜同样。

所以，微服务进阶之路道阻且长，企业须要一个平台级商业产品，能够从业务视角来管理微服务的可视化工具或者平台，下降用户的学习和运维成本，提升用户的业务价值输出能力，帮助用户重塑数字化时代核心竞争力。

-FIN-

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