小型系统如何“微服务”开发

提到“微服务”,我相信网上各种“微服务”的演变案例都会给人一种“因大而分”的前提错觉,这可能会导致许多的“小白”产生没有机会接触“大项目”而对“微服务”可望而不可及也。当然,这种错觉的产生可能更多来源自于各种“微技术”的“层出不穷”所以“眼花缭乱”,例如Spring Cloud。虽然“大项目”机会不多,但也阻止不了“钉子们”通过教程把微技术跑一遍来装饰自己可以“微”起来的自信。

“微”只是一种正常思维逻辑

想当年,入行如赶集,同样作为小白,能把SSH框架跑一遍竟然能给自己带来无比强大的工作自信。谁没个“资本”年龄,只可惜自身的“浮躁”逼退了当年追求“本质”的淡定和沉稳。在网互联网崭露头角的年代,系统的焦点可能不在于“单体”应用的“横向分布”,更多在于对整体业务的“竖向分层”。无论横分还是竖分,“分”的本质其实就是因为“重”。“分而治之”应该算是人类最基本的思维逻辑。只不过“分”的具体实现还得归咎于站在我们对立面的是什么问题。互联网是把“业务”从线下往线上迁移的主要推力,在这个互联网初始发展阶段,需要体现的可能是线上业务的完整性,因此业务的厚度成为了瓶颈,所以对业务逻辑层次的垂直划分可能是当时的关键解。随着移动互联网的普及,“线上业务”已经成为主流,业务的“厚重”已经积累到了另外一种层次,单纯的“竖向分层”已经无法满足厚重业务的积累和支撑。业务横向分解成为了突破口。大量“分布式”方案油然而生,包括“微服务”。从许多“大而微”的初始现象来看,确实很容易把“大”和“微”联系在一起,这也是“大”企业走在时代前沿面对“不确定性机会”所“创造”的现象。历史可以很轻易地给人一种“知其所行”的大局视野,但时代演员却很容易被局限当前。我个人觉得“微服务”的本质就是一种正常的思维,是一种基本解决问题的思路。“微服务”并非新招式,跟二十六种常用面向对象设计模式一样,随着时代经验的积累会成为我们解决问题的“基准招式”。因此也可以大概推测,未来的发展离不开“微服务”思维模式的导向,例如项目或组织的管理模式都可能会发生变化,或者说已经在悄悄地改变。如果说“微服务”确实像我分析的是一种思维模式,那就不会有大项目和小项目之分了。

“微服务”模式小案例

在工作过程中,大项目毕竟少数,小项目才是考验技术人“接地气”的表现所在。有一天,我接到了一个小规模的“话费充值系统”需求,没有太多复杂功能和逻辑的描述,就是一个能让用户在上面自助充值的系统。剩下的理解,靠的就是自身工作经验的功力了。面对这样的需求,我首先想到的就是这个关键业务流程:

这个流程说简单可以简单,说复杂可以“媲美”电商系统,例如“充值金额”相当于商品,“充值”相当于购物,“订单”跑不掉,“充值话费”类比物流。各种电商该有的“边界问题”几乎都要考虑,规模虽小,但五脏都得要有。至于“五脏”有哪些,这得根据业务的边界范围去划分“业务领域”了,先来根据自己的经验尝试一把:

这种业务划分方式多少跟电商系统有点类似,直接呈现的是业务模型。根据“微服务”思维,每个领域都是一个独立的服务个体单元,每个服务“对象”又有自己的“属性”和“行为”:

每个服务的属性有“服务标识”、“服务名称”等,当然服务有自身的各种行为(更多以API体现),各种系统外部动作都是通过服务之间的“合作”来完成:

用户查看充值金额:接查询商品服务(“充值10元到账12元”,“充值100元到账106元”,......);

用户发起话费充值:订单服务接收请求→订单服务查询商品信息(商品ID)→订单服务向支付服务下支付订单→订单服务向充值服务下充值订单→订单服务自身下商品订单;

用户支付:支付网关(外围)接受请求→回调支付服务通知支付结果→支付服务更新支付订单状态→支付服务向充值服务发起充值→充值服务向充值网关(外围)发起充值并更改充值订单状态;

订单对账:定时支付网关对账、定时充值订单对账:

从以上流程可以看出,每个服务都有自己专注的“职能”,每个应用业务流程有需要1或N个服务的交互才能完成,每个服务都有自己独立的“数据源”,互不干扰。由于系统的初期规模预期比较小,可能每天就那么数百笔订单甚至可能更少,如果我们每个服务都需要“物理隔离”,未免有点大题小做。因此,项目初期我们按“单体”模式实施:

所谓的“单体”,即把所有服务代码结合一个“项目”打包发布,也就是一个“普通”的项目并且共用一个数据库,但每个服务的表名都有服务的标识(约定),例如商品服务的相关表名以“KW_GOODS_XXX”命名,订单服务的相关表名以“KW_ORDER_XXX”命名,支付服务的相关表名以“KW_PAYMENT_XXX”命名,充值服务的相关表名以“KW_RECHARGE_XXX”命名,对账服务的相关表名以“KW_ACCOUNT_XXX”命名,服务之间决不能跨越服务操作数据库表,必须按照“业务流程设计”调用,所以“单体”只是体现在物理实施层面,逻辑层面始终保持着“微服务”的分布式特性,保留了各种不用修改一行代码即可灵活扩展的可能性:

可能有人会问,“单体”模式的服务调用怎么调?“分布式”模式又是怎么调?怎么确保扩展时服务代码调用层面的不变?用的是什么技术?这篇随笔就先不谈太多的技术,服务的调用过程我大概通过伪代码图术一下:

服务之间协作的“透明化”关键在于把“微服务”灵活特性所导致的“变化”打包封装起来,就是以上伪代码的DiscoveryClient调用代理。DiscoveryClient在技术框架内维护了所有服务的信息(Service Data Cache Container),而服务信息的加载方式是服务解耦的关键所在。首先,框架通过本地扫描的方式把所有本地服务信息扫描并加载至“服务容器”(本地扫描LocalService)。其次,框架会检测本地的“服务信息”配置文件并加载至容器(静态解析)。最后,框架会根据配置前两步所加载的服务信息判断是否存在“发现中心服务”并动态地周期性向“发现中心”更新服务信息(动态解析)。因此,无论是单体应用部署还是分布式应用部署,对服务调用是透明的,保留了整个系统的灵活扩展性。到这里,整个系统的设计基本完,完整的系统架构图如下所示:

以上系统在无任何优惠的正常运行下,确实只能算得上小规模,一台服务器的单体部署模式足以支撑,但在每月会员日所推出“充100元送10元”商品的时候,单体应用就显得有点力力不从心了,商品服务访问量的增加(看得人多了)已经影响到了其它服务的稳定性,并且考虑对账的稳定性(以免充值不到账引起投诉),决定把商品服务和对账服务独立(进程)部署。通过加入网关(Nginx)进行服务分发(服务解耦):

在运营过程中,公司为了“流量经营”,不惜下血本推出“充100元送50元”的商品,系统再一次受到严峻的考验,为了业务质量,不得不把所有服务独立(进程)部署,增加支撑力度:

不知道是不是老板喝多了还是运营短路了,竟然提个“充值100元送100元”的商品,并明天上线,系统峰值支撑并发量的预测已经超出了我的想象力,我能做的只有这样了:

系统从业务规模来看确实存在大小之分,但从设计思想层面,系统是没有大小之分。以上“戏路”都是以服务为单元进行灵活扩展,其实业务的最小力度是服务的具体行为—API,每个API都是服务的一个独立行为,例如查询、变更等,完全符合“命令查询职责分离(CQRS)模式”的设计,按服务这种API粒度进行横向分解同样可行,例如“支付服务”存在支付订单查询API、支付订单下单API、支付结果通知接收API,我们可以通过读写特性把查询API和变更类API进行分离,同样可以以面向“消费对象”的角度进行分解:

如果某些业务存在服务链复杂的话(例如商品订单),还可以自定义“编排服务”解耦“基础服务”的复杂度:

学习总结

如果细心点可以从以上案例发现,我的整个项目开发过程跟传统的可能会有点区别,什么区别呢?这里没有突出太多的实体对象设计或者表结构设计,更没有突出所谓的“三层结构”设计,而是直接从业务角度触发划分“业务对象”,而我们的服务呈现的是根据业务领域划分的“对象”描述,与传统按“数据实体”划分的设计模式还是有一定的区别,从需求设计到软件设计和开发都是“业务模型”最原始和最直观的呈现,保证了业务准确性并减少了变更的风险成本,同还大大地降低了项目的沟通成本。这种思想有一个更加专业的术语叫“领域驱动设计”。我深知自己距离所谓的“微服务”或者“领域驱动设计”还有一大段距离,并且以上案例还可能存在诸多的细节问题,但这种类似的思想确实是我自身从业务中摸爬滚打并逐步思考和沉淀而形成的设计习惯。不是别人说什么就做什么,而是通过实践去思考和领悟并向真正的源头的“大师们”学习。

原文地址:https://www.cnblogs.com/wcd144140/p/9782823.html

时间: 2024-09-29 04:55:57

小型系统如何“微服务”开发的相关文章

多租户系统微服务开发平台

目录 项目总体架构图 基础业务模块 项目开发更新进度 运维架构图 服务简述 基于SpringBoot2.x.SpringCloud并采用前后端分离的企业级微服务,多租户系统架构微服务开发平台 mPaaS(Microservice PaaS)为租户业务开发.测试.运营及运维开源框架,能有效降低技术门槛.减少研发成本.提升开发效率,协助企业快速搭建稳定高质量的微服务应用;同时还集合各种微服务治理功能和监控功能.模块包括:企业级的认证系统.开发平台.应用监控.慢sql监控.统一日志.单点登录.Redi

mPass 微服务开发平台

mPass (Microservice Pass) 基于SpringBoot2.x.SpringCloud并采用前后端分离的企业级微服务,多租户系统架构微服务开发平台 mPaaS(Microservice PaaS)为租户业务开发.测试.运营及运维开源框架,能有效降低技术门槛.减少研发成本.提升开发效率,协助企业快速搭建稳定高质量的微服务应用;同时还集合各种微服务治理功能和监控功能.模块包括:企业级的认证系统.开发平台.应用监控.慢sql监控.统一日志.单点登录.Redis分布式高速缓存.配置中

微服务开发中的数据架构设计

本文来自作者 陈伟荣 在 GitChat 分享的文章[微服务开发中的数据架构设计] 前言 微服务是当前非常流行的技术框架,通过服务的小型化.原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合.业务的灵活调整组合以及系统的高可用性.为业务创新和业务持续提供了一个良好的基础平台.本文分享在这种技术架构下的数据架构的设计思想以及设计要点,本文包括下面若干内容. 微服务技术框架中的多层数据架构设计 数据架构设计中的要点 要点1:数据易用性 要点2:主.副数据及数据解耦 要点3:分库分表

使用 Dubbo 对遗留单体系统进行微服务改造

摘要: 在 2016 年 11 月份的<技术雷达>中,ThoughtWorks 给予了微服务很高的评价.同时,也有越来越多的组织将实施微服务作为架构演进的一个必选方向.只不过在拥有众多遗留系统的组织内,将曾经的单体系统拆分为微服务并不是一件容易的事情. Credit: Justin Kenneth Rowley. You can find the original photo at flickr. The microservices style of architecture highligh

Hi Developer,微服务开发攻略请查收

微服务开发攻略微服务正成为最热门的系统架构之一.作为一名开发者,是否已经了解微服务?微服务系统?微服务应用模式?如何提升微服务开发能力......本文带你一起学习微服务.1 什么是微服务微服务是架构层的一个概念,通过分解(业务单元),将项目拆解出n个单元,互相没有强依赖关系(解耦),自我准备需要的依赖条件,进而达到可以独立运行,不再受环境与地点上的限制.2 微服务的由来微服务最早由Martin Fowler与James Lewis于2014年共同提出,微服务架构风格是一种使用一套小服务来开发单个

python 微服务开发书中几个方便的python框架

python 微服务开发是一本讲python 如果进行微服务开发的实战类书籍,里面包含了几个很不错的python 模块,记录下,方便后期回顾学习 处理并发的模块 greenlet &&gevent twisted && tornado asyncio web api 模块 当然有好多可以使用的,只记录作者使用的 flask aiohttp 测试 负载测试boom pytest && tox webtest 文档管理 api openapi sphinx(集成

自主搭建CI/CD,为vNext微服务开发保驾护航

简介 微服务开发中自动化.持续化工程十分重要,在成熟的CI/CD环境中项目团队可以灵活分配,大大提供团队效率.如果还不了解什么是CI/CD,可以先查看相关文章,这里主要介绍环境的搭建,相关原理就不过多搬书了. 开始之前 目前主流的ci/cd环境都是基于容器化管理的,所以想要搭建这一环境必须熟练docker操作.版本控制选择git,构建工具选择Jenkins,所以开始前需要先掌握这些技术. 安装docker Ubuntu 18.04 docker安装 docker安装方式有多种,存储库安装方式如下

微服务开发实战(spring-cloud/spring-cloud-alibaba/dubbo),一个案例,手把手带你入门

平日里,都是看别人的文章,虽开公众号写了不少,但像样的不多.年末了,年终总结也没来得及写,为了输出点像样的东西,立刻就着手这个系列.一个键一个字母的敲,边敲边写,文章还在持续更新中,直至完整.相信通过这个系列的系统练习,能有一个大跨步的提升. 专栏简介(是什么?) 结合SpringCloud.SpringCloudAlibaba.Dubbo等开源套件,基于某商场停车业务需求,进行微服务开发实战,力争通过一个案例的实操,掌握微服务架构中常用的技能点,轻松入门. 为什么要写这个专栏(为什么?) 微服

【新书推荐】《ASP.NET Core微服务实战:在云环境中开发、测试和部署跨平台服务》 带你走近微服务开发

<ASP.NET Core 微服务实战>译者序:https://blog.jijiechen.com/post/aspnetcore-microservices-preface-by-translator/ "微服务"的概念在 2014 年正式提出之后,越来越多的团队开始用它来设计自己的业务系统,各种微服务框架和开发过程管理方法也同时兴起.不断成熟.微服务设计方法清晰地定义了各个开发团队的业务边界,微服务框架以不同的方式实现了服务之间的协作与集成,根据康威定律我们可以推导这