返回 登录
0

SOA还是微服务?

阅读945

在构建新的项目时应该总会考虑SOA或者微服务的方式。无论是新建还是重构。都请注意:考虑仍保持开放的选择不采取这种方法。在读完本文之后,关于是否建立多个小部件,你将会有一个更好的方法。
这篇文章是假定你有一些软件架构和服务方面的经验。我将谈一些微服务或SOA,同时在你的项目中该如何做。

图片描述

是微服务?还是SOA?都用?都不用?
有人说,微服务与SOA差别很大。也有人说,微服务与SOA有相同点,但是是SOA的下一代,轻量级和less-enterprisey什么的。

完美构架不存在
你已经知道了没有完美的软件构架方法。Microsoavices可能不适合你的项目,甚至你的公司。什么是microsoavice呢?首先,我想说明这个两个简单的关键点:

  • 细粒度的责任
  • 内置的容错

他们是所有项目的基础,无论你的项目是大还是小。

细粒度的责任
Microsoavices可以是单任务或单个域。下面是一个单任务microsoavice的一个例子。
所有的项目不仅包括业务逻辑和应用领域。总有一些会涉及普通工具。我曾经在一个需要将RTF文件转换为HTML的项目。我们使用了一个库,这是很容易的。另一方面,在更新库时要求我们重新部署应用程序的所有实例。部署是自动化的,同时我们不需要发送新版本给客户,但是对于只有三个人的团队维护几十个实例是要花点时间的。
将相同库封装到一个独立的应用中然后去监听所有的HTTP请求,把它变成一个microsoavice是必要的。总之,从那天起,更新该库只是一个再部署一个单独的组件的事(只要API保持稳定)。
除了单任务microsoavices,还有足够多的用例覆盖应用领域,而不只是单一任务的。拿一个购物车的例子来说。

  • 添加商品到购物车
  • 删除商品
  • 更改商品数量

没有人为这些任务创建单独的服务认真考虑过,这就是为什么它是细粒度的。

内置容错
进程内的方法调用,与外部组件间的调用替换。最大的区别在于,外部调用更容易失败。它需要关注,但适当地考虑了它使整个系统更加稳定和容错设计。
容错真的是一个核心问题。早期把它弄对是microsoavices成功的关键。

问题
构建,部署和维护许多小的,独立的组件组成的系统也带来了许多的问题。你不仅要面对容错的问题,还包括这些问题:

  • 配置(我在哪里实现这一服务?)
  • 监控(提供哪些服务?)
  • 部署(多少实例吗?在哪些主机上运行它们)
  • 测试(在服务呼叫失败的情况下怎么办?)
  • 等等问题

测试和部署应该考虑到持续集成和部署工具可用。中央microsoavice环境的配置可能是一些可以通过使用一些ESB-like工具解决。
似乎有一切的解决方案,你只是不太满意。老实说,我认为我们没有完全到那一步,当涉及到的工具。将来会带来很多很好的工具,使构建,部署和维护microsoavices容易得多。

心态
从我自己的经验来看,我可以说microsoavice不只是关乎技术问题,这真的是还有一些关于心态问题。
如果你担心因为没有单一故障的服务增加的失败的概率,那么你可能需要重新考虑一下了。如果你看到那些小的组件帮助你降低失败的机率,你可能就能很快解决。
不要忘了你是一个开发人员。确保他们用mircosoavices的思想解决问题。我将在以后的工作中,microsoavices如何改变和提高开发人员的工作。

我的经验
我做软件开发近十年了。那段时间我的工作是不同类型的项目。我做了大约90%的网络用的东西Java和JavaScript,以及一些C#.NET,Visual Basic中(预DOTNET),Perl,PHP,Python等等,我做了几年的资深开发人员和架构师,也没遇到过一个人处理从开发到部署和维修的团队。
回想起来,我做了一些项目,一些人会从microsoavice方法中真正受益,一些人可能还没有。我做过一个必须用SOA的项目,非常的不实用,这就是为什么我想写的务实的话题,并从实用角度看待项目。

评论