在过去的几个月中，我一直在关注两种相互独立但相互依存的技术，尽管它们是一个热门话题，但没有多少人谈论何时使用一种或另一种。 我说的是Kafka和Istio 。
两种技术都很棒，并且您可以找到很多演讲，展示如何将这些技术引入您的组织可以改变您的业务，并且它们是对的！ 现在，您是一个巨大的整体应用程序的骄傲的所有者，该应用程序再也没人能理解，也没人愿意接触。 业务部门意识到这是一个问题，因此决定采取措施。 CTO来找您，告诉您：“继续，为我构建一些微服务”。 我从哪里开始？ 如何破坏我的整体应用程序？ 微服务必须有多小？ 更重要的是？ 他们如何互相沟通？ 异步使用Kafka或直接同步调用？
对我来说，这是最难解决的难题，但这不是技术问题，而是更多的业务问题： 它取决于您的业务 。 首先，您的业务流程需要足够成熟才能包含容器和数据流平台。 如果您在PL / SQL上运行报表，则没有自动配置功能，需要等待3个月的时间才能批准更改； 那就算了 从业务开始，定义新的业务战略：围绕业务能力，敏捷实践，自动化以及更重要的是使用域驱动设计构建的小型团队。
但是，假设业务已经准备就绪，如何构建我的第一个基于容器的微服务？ 在宏观层面上， 域驱动设计必须作为您的指南 ，围绕业务功能进行构建，服务必须很小 ，但不能太小； 对我来说，凝聚力是更重要的， 一起变化的事物应该归为一体 。 关键是定义有界上下文及其边界。 微服务应该是独立的 。 将您的应用程序分解为大量相互调用的小型微服务很容易，但是随着系统的发展，它变得极其难以管理，像Istio这样的服务网格是管理这些复杂性的好工具，但是您首先要考虑的是这真的必要吗？ Kafka确实可以简化服务之间的通信，从而为您的微服务创建一个集中式中心，并且您可以使用事件代替直接的服务调用； 但是事件来源也很难实施； 因此为小型组织创建过于复杂的事件驱动架构可能是一场灾难，那么我该如何去做呢？
这是我的方法：
- 使用域驱动设计（ DDD ）定义您的微服务。
- 如果您的服务严重依赖于另一服务的数据，则意味着它们紧密耦合，这可能会引起问题。 您可以使用Istio拥有服务，负载平衡，断路器等的多个副本，以确保服务B的故障不会对您的服务造成太多麻烦，但是会造成麻烦。 因此，如果由于共享数据而使它们如此紧密地耦合在一起，但是DDD和您的组织明确指出应该将它们分开； 然后复制数据 ！，这样做就可以了，这样您就可以拥有独立且一致的独立可部署服务。 您可能有一项服务可以处理销售部门的客户更新，而另一项服务还可以更新索赔部门的客户详细信息。 如果您创建销售和索赔都依赖的微服务，则将很难维护它。 您的技术决策需要与您的组织保持一致； 如果销售和索赔明确分开，那么微服务也是如此。 两者都应该有自己的数据库。 但是，等等，那么每个部门将有不同步的数据，对吗？ Kafka可以在这里进行救援，两个微服务都可以共享Kafka主题，并使用它来实现最终的一致性。
- 从小开始。 您已决定要使用两种微服务来更新客户数据，一种用于销售，另一种用于索赔，之所以这样做，是因为尽管它们会更新同一位客户，但数据却不同。 销售人员将存储来自索赔部门的不同数据。 现在您正在构建用于销售的微服务，是否应该实施事件源？，使用事件存储和物化的超快速只读视图并使用Kafka来同步数据？ 答案是不。 从小处着手，使用MySQL构建服务，共享读写。 如果搜索开始变慢，请添加Elastic Search并使用Kafka进行更新。 如果读取和写入次数过多，请创建一个缓存，并使用相同的Kafka主题同步缓存，然后继续以这种方式进行扩展，但从小做起！
- 您可能会想，我总是可以将自己的微服务与自己的数据库保持一致，并完全依赖Kafka，而无需服务网格！ 这将创建大量重复数据并增加复杂性。 所以我回到DDD和复杂性。 如果您需要调用其他服务，如果不是很重要，请调用它。 Istio可以帮助您管理服务之间的通信。
我的观点是，您不应该完全依赖Istio或Kafka，而是需要明智地使用它。 不要创建复杂的事件驱动架构或复杂的服务网格； 根据您的组织需求创建平衡的体系结构； 并从小做起 ，这是我能给您的最好建议。 对于您的关键服务依赖Kafka，对于其他所有使用Istio功能的应用来说，两者都是很棒的技术！
