微服务架构可扩展性
对于微服务新手来说，演讲中最具启发性的收获之一是有关不同类型的体系结构的比较和对比部分。 Heckler详细介绍了这些内容，以使听众可以轻松掌握其优缺点。
首先在砧板上是笨重的整体。 它的主要功能包括拥有一个单一的逻辑可执行文件，并具有跨功能和非粒度结构的共享数据。 缺点很多。 这种类型的系统很难扩展，任何故障都意味着完全故障，无法更改控制流，它已附加到特定的语言和平台，并且耦合性高，内聚性低。
整体的日子必须编号。 一个内部可能对几百个用户运行良好的系统，设计的目的并不是为数十万个地理位置分散的用户很好地工作。 简而言之，看起来简单的事情从来都不是真正容易处理的。 “小而独立的整体设计的想法是一个浪漫的概念。 即使以这种方式开始，它也不会保持这种状态。”
马克表示，微服务模型的作用远不止于此。 诸如灵活性，可伸缩性和快速性之类的词通常用于描述此体系结构。 但是使这些好处成为可能的功能更加具体。 微服务可以独立部署和执行。 它们支持无中断更改，对多语言友好，可隔离故障，使控制流更改更容易，具有高内聚性和低耦合性，并且易于扩展。 此外，它们具有易于管理的思维模型，对于程序员而言，该模型应该或应该更简单。
微服务不是SOA
与微服务相反，SOA既不敏捷也不快速，正如在企业服务总线鼎盛时期所证明的那样。 该体系结构具有宏服务，SOAP + XML，带有智能管道的哑端点，并且高度耦合。 “在某种程度上，它比微服务更复杂，甚至更灵活。” 另外，“ ESB将领域知识外部化，并合并过程知识。”
微服务具有更多的活动部分，但它们更具针对性。 这种方法使用轻量级的REST，XML和JSON，并具有带有哑管道的智能端点。 与SOA相比，它的好处是灵活性，可伸缩性，可用性，独立的可操作性和效率。 微服务以SOA无法提供的方式提供经过微调的控制。
为了使微服务正常工作，需要进行哪些更改？
到目前为止，与其他服务相比，Heckler的比较描绘了微服务的美好前景。 但他明确指出，有许多障碍需要克服。 “在宏观层面上更加复杂。 这意味着您需要更好的建筑师。” 当然，这并不是要解雇所有人并开始组建新团队。 Mark解释说，这些下一代微服务架构师可能已经在组织内部，但是需要对其进行识别和培养。
企业还必须放弃拥有单个数据存储库的想法。 那必须改变。 但是，从长远来看，这是值得的。 “组合小型的独立代码或数据总是比解耦代码或解析数据要容易得多。” Heckler在演讲中更加详细地介绍了微服务使能器，例如负载平衡器，智能路由器和断路器仪表板，这些工具可以帮助管理和充分利用微服务的广为宣传的好处，同时避免潜在的陷阱。
翻译自: https://www.theserverside.com/blog/Coffee-Talk-Java-News-Stories-and-Opinions/Implementing-a-scalable-microservices-architecture-without-all-the-hype
微服务架构可扩展性
