课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
随着互联网的不断发展,越来越多的人都在学习计算机编程开发技术,而今天我们就简单来了解一下,微服务架构开发注意事项。
设置时间更长
构建一个微服务架构所花费的时间要比将相同的特性整合到一个单体应用中要多得多。尽管单个服务是非常简单的,但是交互的服务集合要远比单一的单体更加复杂。在一个单体中,一个函数可以调用任何其他公共函数。但是,微服务中的函数仅限于调用同一个微服务中的函数。这就需要服务之间的通信。构建API或者消息传递来促进这一点并不容易。而且,跨微服务的代码重复也是不可避免的。当一个单体应用可以一次定义一个模块并多次导入,而微服务是它自己的应用:在每一个模块都必须定义模块和库。
微服务适合大型团队
将微服务分派到各个团队的奢侈做法是留给大型工程部门。尽管这对这个架构来说是一个很大的优势,但是如果你拥有足够的工程师来为每一项服务指定一些工程师,那么这才是可行的。减少代码范围,可以让开发人员对代码有更好的理解,加快开发的速度。但是,大部分的初创公司都没有这样的奢侈。在一个创业早期的公司,由于缺乏足够的资源,有些工程师必须在所有的服务之间工作。遗憾的是,这样做会降低工作效率,因为在不同的应用中跳跃,可能会导致环境的变化。我发现,在我已经很久没有关注的微服务中调查Bug,是一件非常令人筋疲力尽的事情。
DevOps更复杂
选择微服务有说服力的一个原因就是可以在不同类型的服务器上运行不同的服务。这是为什么呢?React前端的内存、CPU和启动时间的需求与训练机器学习模型的服务大相径庭。为每一项服务选择适当的基础架构类型,可以极大地减少费用。但是,这也给自己带来了一个挑战。
举个例子,在我的职业生涯初期,由于忘记重启一个更新过代码的服务,导致我丢失了大量的生产数据。过期的代码会通过API来接收数据,却没有把数据存入数据库,反而消无声息地失败。这样的数据就会永远丢失了。
我之所以提出这一点,是想要表明,配置、维护和监控多个微服务,要比单一的单体应用要复杂得多。拥有多个应用程序,还为骇客增加了多个攻击面。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。