
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
软件架构师是许多软件开发程序员的职业发展方向之一,而成为架构师必然需要掌握不同的软件架构方式,下面我们就简单来了解一下,微服务架构设计应用分析。
1、架构设计
系统的架构设计是一件极度复杂的事情,在工作的这几年大致经历过如下几个阶段:单服务、多服务集群、微服务、持续集成;在近2年比较稳定的选型是微服务+自动化集成的模式:
思考其本质的变化逻辑,即为了应对更复杂的业务体系;不管是业务拆分还是模型设计,都是在不断实现高内聚低耦合的原则;降低业务之间的关联影响,分离业务和技术的高度耦合。
2、业务场景
这里先来看一个的业务场景:电商交易;基于微服务架构的电商交易场景中,通常至少会涉及如下几个核心服务:交易、账户、订单、商品、仓储、物流;
站在业务角度,进行模块化拆分和管理,结合持续集成的组件,通常可以轻松的应对各种复杂的业务场景,但是不存在真正意义上一劳永逸的手段,业务变化带来的各种问题总会无脑推动开发去寻找更合理的解决方案;
在一次完整的电商交易场景中,实际上真正涉及到的微服务远不止图中的几个,在Trade服务中交织关联多个其他服务,在MVC的分层管理下,初期并不会存在较大风险,但是业务一旦经过多版升级改造之后,并且还存在版本兼容的要求,会给人一种极度混乱和不踏实的感觉;
如果团队成员的综合能力较高,并且版本有充足的时间去设计和优化,这种问题是可以妥善解决的,如果出现时间紧任务重的情况,随之而来的压力会持续在开发和测试之间来回横跳;
解决过相关业务场景的研发都知道,重构加持续集成能力,结合严谨的测试,可以应对业务的不断变化;但是在版本兼容的过程中,依然会导致工程中的代码膨胀到飞起,特别是出现中场换人的情况,都会让接手的人员在被埋和离开中,产生一次剧烈的心态挣扎。
3、问题分析
在MVC的架构模式中,工程通常会进行如下的分层管理:控制层、服务层、持久层、存储层;服务层在特定复杂的场景中会做细化拆分,比如三方对接、常用中间件的二次封装:
对于在复杂业务线上争渡的选手来说,对Mvc分层模式的缺陷是深有体会的,Service层聚焦大量复杂的逻辑,通常核心业务块中总会存在几个代码过千行的实现逻辑,不管用什么思路和模式去拆分封装,都很难解决该层不断扩展带来的膨胀问题。
4、面向过程
在MVC分层中,过程式的代码极其明显,通常以数据库表和关系为基础,映射构建相关实体对象,这些实体对象并没有具体的行为和逻辑,只是作为数据和结构的载体:
从面向对象中类的定义去看:属性和行为;而在MVC模式中,绝大多数实体都只是作为数据的入参出参的结构定义,可以理解为数据容器,在MVC的各层之间不断搬运和加工。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。