微服务进阶之路

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

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

***阶段试炼—— 开发新应用

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

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

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

微服务架构并不尽善尽美，适合自己的方案才是王道

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

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

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

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

（编辑：应用网_丽江站长网）

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