让开发回归简单模式-组件封装

这篇具有很好参考价值的文章主要介绍了让开发回归简单模式-组件封装。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

        对于工作年限不长的程序员来说,知识储备是非常关键的。在开发中各种技术的应用已经非常普遍了,例如常见的各种ORM,各种中间件如Redis,MQ等等,又如WebApi路由配置等等,对于常常做开发的程序员来说,都是小事,我们就从小事说起。

        在微服务中,常用到MQ作为微服务之间通讯的桥梁,以RabbitMQ为例,其转发的方式有direct、fanout、topic,而在微服务中的应用,几乎不会使用direct这种交换模式。对于程序员来说,具体使用哪一种交换模式,需要开发时候双方去协商和沟通通讯的数据结构,还要处理通讯过程出现异常的情况,这样下来,从发送和校验到接收和处理,一系列下来,代码少说也有一百几十行,还要话费沟通成本,还需要程序员对mq的掌握。对于组织开发者来说,就是一大堆的培训工作,不培训就要花费时间成本。

        fanout这种交换模式,就如大喇叭,发出去的消息,只要愿意,都能够接收到,是一种比较开放的消息发布模式。例如一个员工的基础信息发生了改变,其他微服务需要更新这个员工的显示信息,那么都来接收就好了,至于接收到怎么处理,那是接收方的事情了,只要接收成功,回应一个ack信号就可以了。

        topic这种交换模式,是具有指定性的,只有匹配到topic字符串的接收方,才能收到消息,就向路由一样。例如做一个系统的内部通知消息,要通知到岗位或者个人,可以使用通配符:

#   匹配多个多个单词,例如message.pos1.emp1 使用message.# 所有消息都能成功匹配上;

*    匹配单个单词,例如message.pos1.* 在pos1下的所有人都能收到这个消息。

        程序员是否需要了解这些?我感觉不需要,我们把发送消息封装成一组类,一个是用于发送,一个是用于接收,例如:

        生产者接口

public interface MQProducer
{
    void Publish<T>(T body);
   
}

         消费者接口

public interface MQConsumer
{
    //使用topic订阅消息
    void Consume(QueueDeclare queue, string topic,Action<string> action);

    //使用fanout订阅消息
    void Consume(QueueDeclare queue,Action<string> action);
}

上述方法,只要稍微了解MQ的,都知道这么封装,在微服务中的消息传递相对比较简单的,可以进一步封装。生产者这一端,可以使用AOP方法制作一个发布消息的标签,例如:

public class SaleSerivce : ServiceBase<SaleHdr,SaleDtl>
{
    //当成功保存单据后,当前微服务ID为AppId,以Sale为资源,SaveBill为action标记发送SaleHdr对象
    [MQPublish]
    public RValue<SaleHdr> SaveBill(SaleHdr hdr,List<SaleDtl> dtls)
    {
    }

    //这里解释一下RValue<T>这个结构
    //当方法体出现异常,RValue<T>接收Exception对象,并设置Success=false;
    //当方法体返回字符串,RValue<T>.Message接收字符串值,并设置Success=false;
    //当方法体返回SaleHdr对象,RValue<T>.Value接收对象,并设置Success=true;
    //MQPublish标签,在Success==true时候把SaleHdr对象包装成一个标准的通讯数据格式后,转成json发送出去
}

        接收端就有点复杂了,对不同交换方式,要开发一套对应的数据接收和转发机制。 首先,接收到的消息,否存到一个消息对象中,然后塞到一个Queue对象中,只要向Queue中加元素,则触发出队列的方法,直到读取Queue完成才终止。

       

public class PurService : SeriveBase<PurHdr,PurDtl>
{
    [MQConsume("saleApp","sale","savebill")] //appid,resource,action
    public RValue<PurHdr> MQSaleSave(SaleHdr saleHdr)
    {
        //当新建销售单的时候,采购查询一下是否需要补货
    }
}

建立一个MQStarter来订阅MQ消息,并根据MQConsume标签上的参数,匹配到方法,可能会匹配到多个方法,没有关系,通通调用一次就可以了。如果RValue<PurHdr>.Success==false ,则做日志,并把消息方到另外一个容器中,允许重试规定次数后再手动重发。

        上述生产者和订阅者,都没有接触到MQ的具体对象和相关代码,只用了两个标签就完成了两个微服务之间的数据交互,只要框架的开发者能够在这个封装中充分考虑到各种情况和处理好各种异常,那么对于程序员来讲是非常轻松的事情,不用考虑通讯协议、结构、方法等等,集中精力编写业务逻辑代码。即使出现通讯问题,只需要反馈就可以了,让开发回归到本质。

        在微服务中,用得最多的就是httpClient、redis这两个组件。

        HttpClient可以根据封装好的WebApi标准接口进行封装,程序员只需要直接调用方法和给参数就可以完成api调用且方便处理好api返回值,转换成所需要的数据结构。

        Redis同理,可以封装成MemoryCache这样的操作方式,分别多String,Hash等数据结构操作。

        为了然程序员最大程度减少对技术依赖,把一些常用或者复杂的工作进行封装,转化为简单的操作方式,例如ORM,特别是使用EF的,往往需要程序员开发时候直接操作EF读写数据,带来的问题,往往没有处理读写时候的异常,导致程序在特定情况下卡死或者报错。这里建议把ORM用一层数据访问层包起来,而这个ORM对象只是一个protected层级的,把常规的读写操作都封装成方法,派生出来的对象,都是使用方法,而不使用ORM对象。即使那天把ORM换掉了,对原来的程序也没有一点影响,例如原来程序使用mysql,后面发现结构很简单,用mongo可能更合适,只要改变一下数据层的实现类就可以了,一般数据层都是注入到系统的,对于部署来说,就只是换了一个dll文件,对于程序员来说,几乎没有影响,除非操作了ORM。

        程序员连最基本的数据库操作对象都不需要了解,甚至可以不知道用了哪种ORM,程序员就纯粹写业务逻辑,可以把业务中的各种复杂情况都考虑仔细。让程序开发真正回归简单化。

        这样带来一个问题,非常不利于程序员的成长,这个就需要程序员在工作过程中注意细节、更多思考,从别人的案例中学习技术技巧,多尝试,转变成真正自己的知识。

        在我的框架中,把事务处理也封装成一个标签,这个是参照java中的写法,只是加了更多自己的想法,把事务嵌套、分布式事务都考虑进去了,例如:

        

[Transaction]  //事务标签,若当前没有在事务中,则发起事务,否则这个标签相当于透明
publice RValue<StoreInHdr> SaveStoreIn(StoreHdr,List<StoreDtl> dtls)
{
    //这里要处理进仓的操作,同时发起分布式事务标记到货单和采购单
    //完成库存的更新
}

这样让程序员完全不用考虑事务过程的处理,至于是提交还是回滚,那就看RValue的返回值。

        对于企业来说,用人是一个很大的风险,找水平高的,不愿意带人,写的代码一般程序员还不一定能看懂,自己还有自己的一套风格,换个人维护就很难了。找水平低的,又不按规则来,考虑问题不仔细,会出很多乱子。通过封装,除了简化了开发难度,也制定了开发规则,使用统一标准,有利于项目的持久迭代和发展。文章来源地址https://www.toymoban.com/news/detail-698733.html

到了这里,关于让开发回归简单模式-组件封装的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【软件开发】大规模分布式系统的容错架构设计

    假设有一个数据库,数据库里有一张特别大的表,里面有几十亿,甚至上百亿的数据。更进一步说,假设这一张表的数据量多达几十个 TB,甚至上百个 TB,那么如果用 MySQL 之类的数据库,单台数据库服务器上的磁盘可能都不够放这一张表的数据! 假如你手头有一个超大的数

    2024年02月04日
    浏览(57)
  • 【分布式技术专题】「单点登录技术架构」一文带领你好好认识以下Saml协议的运作机制和流程模式

    传统上,企业应用程序在公司网络中部署和运行。为了获取有关用户的信息,如用户配置文件和组信息,这些应用程序中的许多都是为与公司目录(如Microsoft Active Directory)集成而构建的。更重要的是,通常使用目录存储和验证用户的凭据。例如,如果您使用在本地运行的Share

    2024年02月05日
    浏览(43)
  • (大数据开发随笔9)Hadoop 3.3.x分布式环境部署——全分布式模式

    分布式文件系统中,HDFS相关的守护进程也分布在不同的机器上,如: NameNode守护进程,尽可能单独部署在一台硬件性能较好的机器中 其他的每台机器上都会部署一个DataNode进程,一般的硬件环境即可 SecondaryNameNode守护进程最好不要和NameNode在同一台机器上 守护进程布局 Name

    2023年04月16日
    浏览(60)
  • Unity与C++网络游戏开发实战:基于VR、AI与分布式架构 【1.6】

    3.8 Unity中使用协程         协程是在Unity中经常使用的一种辅助处理模式。比如,我们需要设计一个人一边走动一边去观察周围的情况,走动和观察这两种运动同时进行。这时我们可以使用多线程来处理这个问题,但是多线程在内存和CPU的调度时间上具有一些风险。此时在

    2024年04月10日
    浏览(47)
  • 封装redis 分布式锁 RedisCallback

            RedisCallback 是redis 一个回调接口,在 Redis 连接后执行单个命令,返回执行命令后的结果。  如果在使用 RedisCallback 时,需要自动获取 Redis 连接资源,使用完毕后并释放连接资源。         RedisTemplate 类提供了一个 execute 方法,用于执行 Redis 命令并返回执行命令

    2024年02月11日
    浏览(24)
  • Android组件化架构开发--为什么要使用组件化?组件分层?组件路由的简单实现。

    1.1 单工程项目结构 一般我们都是一个业务建一个包 缺点: 各种业务代码混杂在同一个模块里,开发人员在开发、调测过程的效率越来越低,定位某个业务问题,需要在多个业务代码混合的模块中寻找和跳转。 需要了解各个业务的功能,避免代码的改动影响其它业务的功能

    2024年02月10日
    浏览(64)
  • 【分布式】分布式存储架构

    说到分布式存储,我们先来看一下传统的存储是怎么个样子。 传统的存储也称为集中式存储, 从概念上可以看出来是具有集中性的,也就是整个存储是集中在一个系统中的,但集中式存储并不是一个单独的设备,是集中在一套系统当中的多个设备,比如下图中的 EMC 存储就需

    2024年02月10日
    浏览(53)
  • 分布式爬虫架构-对等分布式(2)

    前言 本文是该专栏的第45篇,后面会持续分享python爬虫干货知识,记得关注。 在面对海量数据的采集需求时,使用分布式爬虫是非常有必要的。继上一篇,详细介绍主从分布式爬虫架构,对主从分布式相关知识感兴趣的同学,可往前翻阅。而本文,笔者再单独来详细介绍分布

    2023年04月25日
    浏览(55)
  • 【系统架构】分布式系统架构设计

    分布式系统是指由多个计算机节点组成的一个系统,这些节点通过网络互相连接,并协同工作完成某个任务。 与单个计算机相比,分布式系统具有更高的可扩展性、可靠性和性能等优势,因此广泛应用于大规模数据处理、高并发访问、分布式存储等领域。 分布式系统的设计

    2024年02月15日
    浏览(56)
  • 单机架构到分布式架构的演变

    目录 1.单机架构 2.应用数据分离架构 3.应用服务集群架构 4.读写分离 / 主从分离架构 5.引入缓存 —— 冷热分离架构 6.垂直分库 7.业务拆分 —— 微服务 8.容器化引入——容器编排架构 总结          初期,我们需要利用我们精干的技术团队,快速将业务系统投入市场进行

    2024年02月04日
    浏览(47)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包