婚恋网网站架构,上网建站推广,网上服装定制平台,动漫设计就业前景如何对于工作年限不长的程序员来说#xff0c;知识储备是非常关键的。在开发中各种技术的应用已经非常普遍了#xff0c;例如常见的各种ORM,各种中间件如Redis#xff0c;MQ等等#xff0c;又如WebApi路由配置等等#xff0c;对于常常做开发的程序员来说#xff0c;都是小事知识储备是非常关键的。在开发中各种技术的应用已经非常普遍了例如常见的各种ORM,各种中间件如RedisMQ等等又如WebApi路由配置等等对于常常做开发的程序员来说都是小事我们就从小事说起。 在微服务中常用到MQ作为微服务之间通讯的桥梁以RabbitMQ为例其转发的方式有direct、fanout、topic,而在微服务中的应用几乎不会使用direct这种交换模式。对于程序员来说具体使用哪一种交换模式需要开发时候双方去协商和沟通通讯的数据结构还要处理通讯过程出现异常的情况这样下来从发送和校验到接收和处理一系列下来代码少说也有一百几十行还要话费沟通成本还需要程序员对mq的掌握。对于组织开发者来说就是一大堆的培训工作不培训就要花费时间成本。 fanout这种交换模式就如大喇叭发出去的消息只要愿意都能够接收到是一种比较开放的消息发布模式。例如一个员工的基础信息发生了改变其他微服务需要更新这个员工的显示信息那么都来接收就好了至于接收到怎么处理那是接收方的事情了只要接收成功回应一个ack信号就可以了。 topic这种交换模式是具有指定性的只有匹配到topic字符串的接收方才能收到消息就向路由一样。例如做一个系统的内部通知消息要通知到岗位或者个人可以使用通配符
# 匹配多个多个单词例如message.pos1.emp1 使用message.# 所有消息都能成功匹配上
* 匹配单个单词例如message.pos1.* 在pos1下的所有人都能收到这个消息。 程序员是否需要了解这些我感觉不需要我们把发送消息封装成一组类一个是用于发送一个是用于接收例如 生产者接口
public interface MQProducer
{void PublishT(T body);} 消费者接口
public interface MQConsumer
{//使用topic订阅消息void Consume(QueueDeclare queue, string topic,Actionstring action);//使用fanout订阅消息void Consume(QueueDeclare queue,Actionstring action);
}
上述方法只要稍微了解MQ的都知道这么封装在微服务中的消息传递相对比较简单的可以进一步封装。生产者这一端可以使用AOP方法制作一个发布消息的标签例如
public class SaleSerivce : ServiceBaseSaleHdr,SaleDtl
{//当成功保存单据后当前微服务ID为AppId,以Sale为资源SaveBill为action标记发送SaleHdr对象[MQPublish]public RValueSaleHdr SaveBill(SaleHdr hdr,ListSaleDtl dtls){}//这里解释一下RValueT这个结构//当方法体出现异常RValueT接收Exception对象并设置Successfalse;//当方法体返回字符串RValueT.Message接收字符串值并设置Successfalse;//当方法体返回SaleHdr对象RValueT.Value接收对象并设置Successtrue;//MQPublish标签在Successtrue时候把SaleHdr对象包装成一个标准的通讯数据格式后转成json发送出去
} 接收端就有点复杂了对不同交换方式要开发一套对应的数据接收和转发机制。 首先接收到的消息否存到一个消息对象中然后塞到一个Queue对象中只要向Queue中加元素则触发出队列的方法直到读取Queue完成才终止。 public class PurService : SeriveBasePurHdr,PurDtl
{[MQConsume(saleApp,sale,savebill)] //appid,resource,actionpublic RValuePurHdr MQSaleSave(SaleHdr saleHdr){//当新建销售单的时候采购查询一下是否需要补货}
}
建立一个MQStarter来订阅MQ消息并根据MQConsume标签上的参数匹配到方法可能会匹配到多个方法没有关系通通调用一次就可以了。如果RValuePurHdr.Successfalse ,则做日志并把消息方到另外一个容器中允许重试规定次数后再手动重发。 上述生产者和订阅者都没有接触到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 RValueStoreInHdr SaveStoreIn(StoreHdr,ListStoreDtl dtls)
{//这里要处理进仓的操作同时发起分布式事务标记到货单和采购单//完成库存的更新
}
这样让程序员完全不用考虑事务过程的处理至于是提交还是回滚那就看RValue的返回值。 对于企业来说用人是一个很大的风险找水平高的不愿意带人写的代码一般程序员还不一定能看懂自己还有自己的一套风格换个人维护就很难了。找水平低的又不按规则来考虑问题不仔细会出很多乱子。通过封装除了简化了开发难度也制定了开发规则使用统一标准有利于项目的持久迭代和发展。
