我们将首先询问一些有关微服务的基本问题：
- 什么是微服务？
- 什么是微服务架构？
- 我的架构中应该有多少微服务？
- 它们应该有多大？
- 我的整个架构是否应该由微服务组成才能拥有微服务架构？
什么是微服务？
服务是可独立部署和可扩展的，每个服务还提供牢固的模块边界，甚至允许用不同的编程语言编写不同的服务。它们也可以由不同的团队管理。
您将看到的典型微服务架构将如下所示：
典型微服务架构图
每个微服务都可以自行部署和扩展。它们作为独立进程运行并通过网络进行通信。每个都有自己的数据库。
微服务架构图在整个系统中共享用户界面。
典型的微服务架构所有权
现实情况是，软件系统比我们想象的更加流畅和动态。
这比我们希望的要难。
软件架构涉及采用许多较小的想法并将它们以对您的用例有意义的方式组合在一起。
一个实际的例子
想象一个拥有现有遗留系统的企业。
这种单一的系统通常很容易改变。企业需要一些新功能更快的上市时间。
我们是否应该将整个系统重写为微服务的集合？
通过拥有专用业务功能的集中和封装服务添加新功能会更有意义。
微服务为整个系统增加了额外的功能
这将更像是一种软件架构的进化方法（继续阅读）
微服务需要拥有给定业务上下文的数据、行为和 UI。
结论
你应该使用微服务架构吗？
没有。
您应该做对您的业务有意义的事情。
例如，您的企业可能想要构建需要快速上市的新产品。
您可以将这些新产品添加为完全独立的整体，通过事件消息相互通信，以保持它们松散耦合。
新的单体被分离和封装
它们可以构建为微服务，通过 HTTP REST 调用或事件消息集成回现有系统？
通过微服务增强的现有单体
也许您的公司可以购买现有的现成解决方案？您可以在顶部构建自定义 API，以允许与现有系统集成。
现成的解决方案（想想 CRM 等），带有用于集成的自定义外观
在某些情况下，需要将现有系统拆分为独立的组件。它们可能是微服务。
标签：应该,架构,它们,什么,系统,服务,现有 From： https://www.cnblogs.com/friend/p/16768526.html