微服务架构下常见的四个技术难题
实务上时常伴随对决的痛点
大卫·皮斯诺伊( David Pisnoy)在Unsplash上拍摄的照片
推广微服务架构后，服务颗粒度缩小了，一般要面对更多细节和以前很少出现的问题。原本架构者习惯的开发方法和程序也不得不改变，甚至要思考未曾思考过的问题。
是过去很简单的内部调用、方法、模组机制，在微服务架构下，被集中在服务器集中展示，而不是仅仅围绕在 CPU、记忆体等硬件之外，各种调用者的安全性、选择性或者其他的引用，都可以变成必须要考量的标题，另外要开发者选择考量。
实务针对一些常见的技术问题，开发者和架构师在设计自己的微应用程序时，时常会决。债主在之外，也免不了为未来埋葬工具。因此，很多时候避嫌比较好。
有此比较，将尝试整理常见的技术问题：
- 来回网路通讯问题（往返问题）
- 跨服务呼叫导致的效率降低
- 跨服务的资料维护问题
- 资料一致性问题
来回网路通讯问题（往返问题）
当我们的工作实例生成一个任务后，并设计好API，服务和服务会之间的调用。调用另一个服务的API，各种查询作业。
你像这样想像路，每当一个环境的触发，你就可以开始对另一个服务进行额外的服务，可以为外部提供服务，除了有大量的来回网路通讯外，对有压力的来回网路通讯，对被呼叫的服务，也是相当重要的影响，甚至会严重影响服务反应的速度。
翻译：当A服务为查询每个座标的相关信息，而大量调用B服务API
这个，比较简单的做法，是考虑将 API 设计成简单的问题（Batch）处理的大量问题，避免调用需要单独调用的 API。时间，考虑是否将API设计成非同步（异步）机制，避免服务间通讯期的意外发生。
如果服务的欢迎，没有其他关联服务共享的需求，则可以考虑合并两种服务，来减少跨渠道的服务。设计上，或者服务者可以将需求转变成“服务”模式，对需要比较长时间的业务处理工作进行妥当的管理。
另外，有与其他服务模式可以共享的需求，也可以考虑服务。至于在的同步上，则可以合并使用CQRS，实现资料库化（Database Per Service）关于CQRS的说明和实现方式，参考另外两篇旧文“浅谈CQRS的实现与困难”和“应用层CQRS的实现与困难”。
当这一次问题发生时，仔细检查并仔细检查并考虑是否不过度以服务。
跨服务呼叫导致的效率降低
整个服务架构下服务间机制都依赖着 API 进行，而且一个环扣一环，一个服务还紧接着下一个服务。其中一个调用失败，任务就失败了。这意味着，API 的稳定性代表了整个系统的稳定性。
跨服务调用，关乎整个任务执行成败
你代表服务出错有虫子（Bug），只要会出现问题问题可以。但实际上是，后来的解决方案并不完全是应用程序，而是部署平台启动。现代容器平台，都提供了上面有很好的可用（HA，高可用性）机制，但问题是在转移、管理我们的容器时，免去了的高限制阻止中的服务实例。这导致了服务的极权平台中断，甚至是做不到的工作，都可能被强制中止。
为了解决这样的问题，重试和容错机制就必须实现，这个问题平台上的问题容错机制的压力会怎样叫方，要左右为难。不过自担心，更多建立和建立连线的负载均衡器代理会帮我们避免。
只是其中一个但还是在难免，尤其是各个状态调用所的时间比较长，导致保持连线的比较长，如果最近的机率比较高。很大，每次重连后重新处理很耗系统效果。
非同步的API设计
为了减少 API 的连线状态，以及资源占用问题所采用的方式，采用非同步传递模式的 API 会是比较等当的作法时间。然后同步模式的有什么方法，比如异步 API 的，或者消息伫列（Message Queue）传递资料。
跨服务的资料维护
数据库私有化（Database Per Service）是下会出现的微资料管理模式，而外部系统访问服务的资料库时，可以通过该服务所提供的API。转移在不同的服务和资料库中，无论资料有没有关联性，导致资料管理维护上很多。
服务各自拥有独立的资料库系统
维护涉及到两个层次的有关资料问题：
- 交易机制（Transaction）
- 资料一致性
关于在本文的最后一点交易的一致性，因此只是我们在小节的议题机制。及概念，更进的作法和细节，甚至阶梯涉及程序的实作及API的定义比较，难三言两语交代清楚，日后另作文说明。
过去交易机制（Transaction）的方法，因为半依赖着资料库本身实现了支持资料的机制，在我们多个服务库中。但微架构，下库不再是共享共享的形式，若要多资料库间交易（交易）机制，传统在不同资料库实施的两阶段提交（Two-Phase Commit）便不再适用，而要转向寻求式交易的机制。
要跨服务的交易机制，比较常见的会结合SAGA模式，而SAGA又分为实现方式：
- 化设计的编排（编排式中心式、协作式）
- 去中化设计的编舞（编舞式）
其复杂程度是巨大的，我们除了提供顾问分配咨询外工作解决方案，也为开发者提供了“一个开箱使用的解决方案” 。
化中心设计的编排
编排上比较能受到开发人员的控制，因为的交易和控制，掌握在队伍中的程序上，由该程序进行，逻辑变更，还是要回滚、去支手，无论什么都在进行同支方案可以完成。
去中心化设计的编舞
而编排上，虽然在概念上并不困难，但对于开发人员来说，也只需要看触发而做的事情，相对来说比较弹性。的事件处理分支，会随着成长而变化复杂，需要在工作的配套系统中进行一些工作。
在架构上，交易机制的意义，不再只是微服务表层，而升级到之后的应用层。
资料一致性
各自的资料库其状态服务可能
而前一节所讲述的，资料一致是另一个在资料管理维护后，会产生。的资料则进行某种状态的问题，要寻找 CQRS 索取资料库和服务状态的同步。
另外，纵使我们已经采用了各种资料同步的机制，但仍然在资料一致上仍会发生一些事情，一般来说问题发生的原因如下：
- 服务时间传递、处理的差额
- 系统异常
首先要了解，下一个任务的问题肯定会存在，因为被分割在不同的系统中，除了运行，其中的网路连线、时机、时机以及结果聚合的时间，造成的主要原因是延迟顺便说一下，这些延迟的时间非常少，当几乎可以服务同一个内部网路，甚至是同台机器上，其中的延迟时间不计入。
说这些应用上，这些系统延迟可能会释放不计，但在某些特定的应用上，却不能完全适应，根据需要特别延迟和优化。 ，请先确定任务是否有针对迟到的强烈要求，如果没有，就没有解决的必要。
系统发现异常等（例如、环境问题等，如果按照系统内容的同步，系统放出信息是自己的情况发生的）。最终一致的要求。
如果是采用现成的 CQRS 方案，则不用担心，这通常都是在相关解决方案的支持范围内。
后记
微架构的各种设计模式（Design Pattern，同时服务都涉及了不同的实际事务问题，所以你会在不同的问题中看到同样的设计模式的不同给出的，例如 CQRS 会在数据中出现大量一致性、所以，各种设计模式，是微服务架构的重要功课。
，如果您对微服务架构和生态有任何疑问，则需要对技术上的评估和建议，欢迎与我们Brobridge，取得专业的培训和顾问联系服务。
