
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
微服务架构开发技术的学习与应用是目前大多数软件编程开发程序员都需要掌握的一个编程技术,而本文我们就简单来了解一下,服务拆封与架构选型方法。
1、服务拆分与聚合
前提:服务拆分与聚合在本篇文章中暂时不考虑web的微服务化设计,只说明后端服务的拆分与聚合实践。
服务拆分与聚合需要遵循的原则:服务一定是围绕业务的。但事实情况是,在现在追求“开源整合”的背景下,纯粹的业务单元在不借助工具的前提下,需要消耗巨大的代价才能实现业务需求,同时也出现不同业务单元对同一个工具的强依赖性。因此在服务拆分与聚合时,我们考虑了两种形态的实现方式:业务支撑与工具支撑。
业务支撑
业务支撑需要考虑的是业务服务对象和业务内部逻辑。业务服务对象作为整个业务单元的对外形态,通过命名能够清晰的表达其涵盖的业务范围;业务内部逻辑需要对业务单元进行细粒度的拆分,类似一个实体类可以包括多个其他相关联的实体对象(当然如果服务拆分的足够细化,也可以把内部逻辑作为独立的业务单元,但是这样会加重业务直接的通信负载)。基于业务内部逻辑构建业务服务对象的真实场景。具体的拆分细节可以依赖DDD的实践方法进行(当然也需要根据业务做相应调整,没有普世之道)。
工具支撑
工具支撑需要结合业务考虑,分为两种:通用性工具和专用性工具。通用性工具旨在为所有业务单元运行提供统一的支撑平台,从而减少由于工具维护花费的精力,使得业务开发人员聚焦业务实现,一般通用工具包包括统一日志处理,统一拦截处理,返回数据统一封装,异常统一处理等等;专用性工具聚焦某个具体的业务单元,由业务单元自身维护(例如迭代升级)。工具支撑层面不会提供对外restful或者rpc的接口,对外的表现形式为编译好的依赖工具包(例如Github的管理接口的封装)。
2、服务架构选型
依照执行原则完成服务拆分以后,我们需要考虑的是合适的落地选型。选型方案要考虑的因素有很多:技术背景(尤其是团队内编程语言的设定),服务支撑工具(注册中心,网关,服务调用,负载均衡数据库等),服务运行工具(tomcat,jetty,jboss等),服务部署工具(物理部署,虚拟化,容器等),工具的协议支撑集合(http,rpc,mtqq,idoc等)。但是无论如何选型终一定要结合团队开发人员当下的技能支撑,这也是我们选型的核心因素,因为白盒相对来说始终比黑盒安全,也相对可控。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。