课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
微服务架构是目前大多数软件开发程序员都在学习和使用的一种架构方式,下面我们就通过案例分析来了解一下,微服务架构技术应用都有哪些注意事项。
让所有人都参与重构工作,需要我们积极宣传这种公司内前所未有的可靠性新模式。为了将可靠性打造成团队将要构建的新系统的基本属性,我们投入了大量的精力。除了关注可靠性外,我们还特别强调隔离性,这是我们在单体开发中不曾考虑的因素。在这方面,核心问题是控制反模式的使用,同时在提取敏捷性和技术债务之间寻找一种合理的平衡。
工程团队面临的主要挑战是要为新创建的服务定义新的交互接口,并着手提取功能,而不仅仅是提取代码。这项工作很难,因为在这个过程中,团队不仅要迁移到不同的技术栈,又要完成新特性开发任务。事实上,我们不可能在整个提取期间都使代码处于冻结状态,因为我们还是需要开发新功能来保持业务的增长,并适应客户、商家和Dasher不断变化的需求。
此外,不同领域代码提取的速度不同,增加了服务采用的难度。事实上,起初的提取工作并没有提供所有的下游依赖,从而完全迁移到基于微服务的架构。因此,团队不得不先采用临时解决方案,如直接访问数据库,然后等待API在相应的服务中落地。即使我们可以在提取过程中采用这样的反模式,表迁移也还是比较困难,因为我们没有一种清晰定义的数据访问模式。我们使用临时API来缓解这个问题,但这种方法增加了总的技术债务。因此,至关重要的是,要对采用过程进行持续监控,并在新的提取工作成功完成后进行推广应用。
复杂的一项工作是数据迁移,从主数据库迁移到新创建的服务专属的数据库,而又不中断业务。这个过程既重要又复杂,而且还存在潜在的破坏性,需要多次迭代才能为批迁移打下基础。
值得注意的是,所有这些工作都是在食品配送市场受新冠影响订单量大幅增长的情况下完成的。在进行代码提取和数据迁移的同时,我们还要确保当前的架构能够处理不断增加的负载。同时处理所有这些因素可不是一件容易的事。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。