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

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

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

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

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

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

第二件事，审视我们自己的业务：
1.上述单体架构列出的一些问题是否已经严重影响了我们的业务？
2.企业新的业务系统是否要满足快速迭代、弹性等需求？
3.团队内是否有 DevOps 氛围？
4.企业内是否有足够的动力和技术储备去接触新的技术？

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

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

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

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

第一步可以选择 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，这样就实现了这些模块的无状态化。

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

第二阶段进阶—— 改造遗留应用

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!