要想下班早，微服务架构少不了

网上流传着很多关于程序员和产品经理的段子，比如有程序员为了应对产品经理的需求变更，连续通宵加班改代码，都累晕过去了，怎么都叫不醒，最后产品经理喊了一句：“小程，我这里有两个需求还要再改改，你看看怎么改？”程序员嘭的一下就弹起来了，说：“你还有什么要求，我还可以，我还能改，下班前就能改完。”

这些虽然是段子，但是在现实生活中，需求也是随着用户的使用不断变更的，程序员经常要面对各种各样的需求变更，那么，怎么让我们更快的适应这些需求变更，更快的迭代交互版本呢？非常火热的微服务和微服务架构，又能给我们的软件开发带来什么好处和方便呢？不着急，后面慢慢道来。

举个例子，最开始，张三和李四看到最近微商很火，他们也想开发一个微信小程序做微商，线上卖货，把家乡的特产卖出去，最开始需求就很简单，有一个微信小程序，用户可以在小程序上浏览和选购商品就可以，在后台，需要管理商品、用户和订单数据。张三作为程序员梳理了一下，主要有如下功能点：

小程序前端：

用户注册、登录

商品展示

下单购买

后台：

用户管理

商品管理

订单管理

整个功能简单明了，张三作为资深程序员，很快就完成了代码的开发，在部署时，出于安全考虑，小明还将前端和后台做了分离部署，很快，小明从华为云上购买了ECS和RDS服务，将开发的应用部署上去，对接好微信小程序平台，小程序就上线了，整体架构如下图：

图1 最开始的整体架构图

小程序上线以后，由于家乡的特产原生态、质量好、风味佳，大受欢迎，顾客们好评如潮，张三和李四开始躺着数钱，做梦都笑不醒。可是好景不长，看到他们做的这么红火，其它人也开始抄袭并快速上线，极大的影响了张三他们的收入，在残酷的竞争压力下，张三和李四决定做一些营销活动，来发展和留住客户，增加收入。营销活动主要有如下的内容：

拓展商品品类：以商城的形式销售其它厂家的商品

拓展渠道：新增网页版入口和单独的APP入口，即上线网页版、上线独立APP等；

促销活动：比如满减、打折、充值优惠、会员优惠、会员积分兑换等

精准营销：购买一些三方数据，根据用户画像进行推送等等。

这些扩展的需求都需要开发程序来支持，张三这个时候就忙不过来了，因此他们新招了一个程序员王五，来一起开发，这次进行了分工，王五主要负责数据分析、会员业务及APP和网页版的开发，张三负责促销活动相关功能的开发。由于要快速上线，张三和王五头脑风暴了一把以后，大致对系统做了一下划分，主要把促销管理、数据分析、会员管理、对接第三方厂家数据等放到后台里，网页和移动端APP另外搭建，忙活了一个多星期，张三和王五完成了基本功能的开发，当前的整体架构如下：

图2 增加促销和单独入口后的架构图

这一阶段存在很多不合理的地方：

小程序、APP和网站3个前端分别开发，有较多的重复开发工作。

所有数据都存在一个数据库中，促销时订单数据等的访问影响会员管理等数据访问的性能，出现过促销时用户无法充会员的情况，流失收入

数据共享有时是通过数据库共享的，有些又通过应用间的接口来提供，应用间相互耦合，依赖关系混乱。

单个应用上不停的扩充功能，应用功能越来越多，代码也越来越多，维护和开发都越来越复杂，且应用上线周期变长，上线后如有问题影响变大。

后台之间相互影响，用户管理影响会员管理，订单管理也会影响用户和会员管理，后台逻辑混乱，维护坤看。

数据库表结构被多个应用依赖，无法重构和优化。

数据分析使用数据库存储数据来实现，且与实时业务库在同一个库，数据分析消耗大量的数据库性能，影响业务访问数据库的性能，页面出现卡顿等。

生产环境的维护变得困难，生产环境的升级变更变得困难，由于不解耦，修改功能后需要前端和后台同时上线，变更时会影响用户使用，需要停服变更等，这样变更时间就只能放到凌晨，开发和运维都很累。

在后台中的公共功能开发，出现程序员之间相互推诿的情况，每个人都觉得公共功能应该有对方开发，自己只做自己负责的业务开发，要不就是都单独开发，代码冗余越来越多。

虽然存在着很多问题，但也不能否认这一阶段的成果：程序员们快速的完成了系统的开发，并适应业务的变化，完成了新的业务开发，不过因为都是快速开发上线，开发过程中都容易只着眼于快速实现业务功能，容易陷入局部、短浅的思维方式，针对功能妥协，缺乏全局的、长远的设计，也缺乏对扩展性、性能等的设计和考虑，长此以往，系统建设将会越来越困难，甚至陷入不断推翻、重建的循环。

张三和王五都是有追求的程序员，他们对现状不满，当线上运行稍微稳定以后，他们去学习了业界流行的微服务架构，并系统的开始对商城进行梳理，开始梳理系统的整体架构并进行微服务改造，他们开始对系统进行抽象，他们重新梳理了商城的业务逻辑，抽象出公共的能力，做成公共的微服务，主要如下：

用户服务

会员服务

商品服务

订单服务

促销服务

数据分析服务

抽象完成后，各个应用服务只需要从公共服务获取所需的数据，删除了大量的冗余代码。然后针对之前数据库性能瓶颈问题和数据管理混乱和数据库表结构复杂的问题，张三他们分析，如果继续保持共用数据库，则整个架构会持续的僵化，失去了微服务设计的意义，因此他们一鼓作气，将数据库也进行了拆分，并引入了消息队列实现系统的解耦和通信的实时性，引入数据仓库来进行数据分析，梳理完后的整体架构如下：

图3 微服务改造和数据库分离后的架构图

如上图，完全拆分后各个服务可以采用异构的技术，每个服务可以使用独立的技术栈单独开发，每个服务都可以单独的部署上线。比如数据分析服务可以使用华为云数据仓库作为持久化层，以便于高效地做一些统计计算；商品服务和会员服务访问频率比较大，因此使用华为云DCS来作为缓存，加入了缓存机制等。微服务之间使用了华为云的DMS来进行消息通信，提升了消息通信的速度同时服务间实现了更好的解耦。微服务架构要求服务都单独的使用数据库，优点是明显的，服务间完全隔离，但数据库拆分也有一些问题和挑战：比如说跨库级联的需求，通过服务查询数据颗粒度的粗细问题等。但是这些问题可以通过合理的设计来解决。总体来说，数据库拆分是一个利大于弊的。

微服务架构还有一个技术外的好处，它使整个系统的分工更加明确，责任更加清晰，每个人专心负责为其他人提供更好的服务。在单体应用的时代，公共的业务功能经常没有明确的归属。最后要么各做各的，每个人都重新实现了一遍；要么是随机一个人（一般是能力比较强或者比较热心的人）做到他负责的应用里面。在后者的情况下，这个人在负责自己应用之外，还要额外负责给别人提供这些公共的功能——而这个功能本来是无人负责的，仅仅因为他能力较强/比较热心，就莫名地背锅（这种情况还被美其名曰能者多劳）。结果最后大家都不愿意提供公共的功能。长此以往，团队里的人渐渐变得各自为政，不再关心全局的架构设计。

从这个角度上看，使用微服务架构同时也需要组织结构做相应的调整。所以说做微服务改造需要管理者的支持。改造完成后，张三和王五分清楚各自的锅。两人十分满意，对系统和当前的开发模式都很满意。

但是，微服务架构调整完以后，就没有其他问题了吗？未完待续……

附：华为云现在提供微服务专家服务，为云为客户提供专属微服务咨询服务，以“适用性评估，目标制定，差距分析，试点实施，效果评估，经验固化”全面指导为设计思路，协助客户高效、低成本的完成微服务规范、工具、平台和流程等整套体系建设，提升业务创新效率。

【参考资料】

华为云微服务专家服务

微服务架构-https://insights.thoughtworks.cn/microservices-martin-fowler/

Wiki百科微服务：https://zh.wikipedia.org/wiki/%E5%BE%AE%E6%9C%8D%E5%8B%99

自动化测试 软件开发

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。