什么是微服务?
我们将首先询问一些有关微服务的基本问题:
- 什么是微服务?
- 什么是微服务架构?
- 我的架构中应该有多少微服务?
- 它们应该有多大?
- 我的整个架构是否应该由微服务组成才能拥有微服务架构?
什么是微服务?
服务是可独立部署和可扩展的,每个服务还提供牢固的模块边界,甚至允许用不同的编程语言编写不同的服务。它们也可以由不同的团队管理。
您将看到的典型微服务架构将如下所示:
典型微服务架构图
每个微服务都可以自行部署和扩展。它们作为独立进程运行并通过网络进行通信。每个都有自己的数据库。
微服务架构图在整个系统中共享用户界面。
典型的微服务架构所有权
现实情况是,软件系统比我们想象的更加流畅和动态。
这比我们希望的要难。
软件架构涉及采用许多较小的想法并将它们以对您的用例有意义的方式组合在一起。
一个实际的例子
想象一个拥有现有遗留系统的企业。
这种单一的系统通常很容易改变。企业需要一些新功能更快的上市时间。
我们是否应该将整个系统重写为微服务的集合?
通过拥有专用业务功能的集中和封装服务添加新功能会更有意义。
微服务为整个系统增加了额外的功能
这将更像是一种软件架构的进化方法(继续阅读)
微服务需要拥有给定业务上下文的数据、行为和 UI。
结论
你应该使用微服务架构吗?
没有。
您应该做对您的业务有意义的事情。
例如,您的企业可能想要构建需要快速上市的新产品。
您可以将这些新产品添加为完全独立的整体,通过事件消息相互通信,以保持它们松散耦合。
新的单体被分离和封装
它们可以构建为微服务,通过 HTTP REST 调用或事件消息集成回现有系统?
通过微服务增强的现有单体
也许您的公司可以购买现有的现成解决方案?您可以在顶部构建自定义 API,以允许与现有系统集成。
现成的解决方案(想想 CRM 等),带有用于集成的自定义外观
在某些情况下,需要将现有系统拆分为独立的组件。它们可能是微服务。
基于微服务的解决方案的优点
这样的基于微服务的解决方案有许多优点:
每个微服务相对较小,易于管理和发展。 尤其是在下列情况下:
-
易于开发者理解和快速提高工作效率。
-
容器启动速度快,从而提高开发者工作效率。
-
Visual Studio 这样的 IDE 可以快速加载较小项目,从而提高开发者工作效率。
-
每个微服务可以彼此独立地设计、开发和部署,这可提供灵活性,因为可更轻松地经常部署微服务的新版本。
可以横向扩展应用程序的各个区域。 例如,目录服务或购物篮服务可能需要横向扩展,但不需要横向扩展订购流程。 与整体式体系结构相比,微服务基础结构在横向扩展时的资源使用更高效。
可以在多个团队之间划分开发工作。 每个服务可以由一个开发团队所有。 每个团队可以独立于其他团队管理、开发、部署和缩放其服务。
可以更好地隔离问题。 如果一个服务出现一个问题,最初只影响该服务(除非使用了错误设计,微服务之间有直接依赖项),其他服务可继续处理请求。 与此相反,整体式部署体系结构中的一个异常组件可影响整个系统,尤其是涉及资源(如内存泄露)时。 此外,解决微服务问题后,可仅部署受影响的微服务,而不影响应用程序的其他部分。
可以使用最新技术。 由于可开始独立开发服务,然后并行运行这些服务(得益于容器和 .NET),因此可以方便地开始使用最新技术和框架,而不受整个应用程序较旧堆栈或框架的限制。