课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
对于程序员来说,不同的开发场景下我们需要选择更合适的软件架构方法,下面我们就通过案例分析来了解一下,单体架构到微服务的转型需要关注哪些问题。
在单体环境中,配置并运行应用程序更简单,不用考虑复杂的依赖关系,拉取所有必要的依赖项。新建一个Hubber,只需几个小时就可以在本机上配置好并运行起来。在单体架构中,代码在有些情况下会更简洁。例如,不用添加超时处理逻辑,也不用考虑如何优雅地处理由网络延迟和中断所导致的失败。
此外,由于所有人都工作在同一个技术栈上,大家对代码库都很熟悉,所以可以方便地将开发人员和团队调去开发单体的其他特性,有利于实现特性的全局优化。
例如,建立具有系统级所有权的特性团队,通过清晰定义的API契约确立职责边界。在遵循API契约的前提下,团队有充分的自由选择适合自己的技术栈。代码库更小意味着阅读更容易、启动速度更快、问题排查更简单。开发人员不用为了提高生产力去理解一整个庞大的代码库的内部运行机制。重要的是,服务现在可以根据各自的需求单独扩展。
监控、CI/CD、容器化都不是什么新概念,但为了支持从单体到微服务的转型,节省时间,加速向微服务的过渡,运营要做必要的改变。在修改这些工作流时,要时刻记着微服务的特性。与为一个大型单体运行单个高度定制化的管道相比,为众多小型的、独立运行的、基于不同技术栈的服务提供运营支持存在很大的差别。将监控从功能调用指标升级为网络指标和契约接口。推动实现自动化程度更高、更可靠的CI/CD管道,并使其可以在服务之间共享。使用容器化技术支持各种语言和技术栈。创建工作流模板以实现重用。
【免责声明】本文系本网编辑部分转载,转载目的在于传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题,请在30日内与管理员联系,我们会予以更改或删除相关文章,以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。