停止盲目利用微服务
发布时间：2022-02-28 04:23:59 所属栏目：业界 来源：互联网
导读：为什么大多数公司最好要避免使用微服务呢？微服务看起来是一种很好的解决方案。从理论上讲，微服务可以加快开发速度，同时允许你独立扩展应用程序的不同部分。但在现实中，微服务是有隐藏成本的。也就是说，我认为，在没有亲自构建微服务之前，你不可能理解
|
为什么大多数公司最好要避免使用微服务呢？微服务看起来是一种很好的解决方案。从理论上讲，微服务可以加快开发速度，同时允许你独立扩展应用程序的不同部分。但在现实中，微服务是有隐藏成本的。也就是说，我认为，在没有亲自构建微服务之前，你不可能理解它们有多复杂。 下面是我在构建微服务（有时是失败的）时所学到的经验心得。 微服务最适合大型团队 将微服务分派到各个团队的奢侈做法是留给大型工程部门。尽管这对这个架构来说是一个很大的优势，但是如果你拥有足够的工程师来为每一项服务指定一些工程师，那么这才是可行的。减少代码范围，可以让开发人员对代码有更好的理解，加快开发的速度。但是，大部分的初创公司都没有这样的奢侈。在一个创业早期的公司，由于缺乏足够的资源，有些工程师必须在所有的服务之间工作。遗憾的是，这样做会降低工作效率，因为在不同的应用中跳跃，可能会导致环境的变化。我发现，在我已经很久没有关注的微服务中调查 Bug，是一件非常令人筋疲力尽的事情。 DevOps 更复杂 选择微服务最有说服力的一个原因就是可以在不同类型的服务器上运行不同的服务。这是为什么呢？React 前端的内存、CPU 和启动时间的需求与训练机器学习模型的服务大相径庭。为每一项服务选择适当的基础架构类型，可以极大地减少费用。但是，这也给自己带来了一个挑战。 举个例子，在我的职业生涯初期，由于忘记重启一个更新过代码的服务，导致我丢失了大量的生产数据。过期的代码会通过 API 来接收数据，却没有把数据存入数据库，反而消无声息地失败。这样的数据就会永远丢失了。 我之所以提出这一点，是想要表明，配置、维护和监控多个微服务，要比单一的单体应用要复杂得多。拥有多个应用程序，还为骇客增加了多个攻击面。 从理论上讲，“松散耦合”的服务允许每个服务在其他服务失败时继续工作。但这只是一厢情愿的想法：对于有客户的复杂业务来说，很难实现真正的松散耦合。 最终，你的应用程序架构的可靠程度取决于最薄弱的部分。移动的碎片越多，出错的可能性就越大。 （编辑：厦门网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
