微服务架构

Eventuate Tram Saga框架是使用JDBC / JPA的Java微服务的Saga框架。 微服务架构遇到的主要挑战是维护跨服务的数据一致性。每项微服务都有自己的私有数据，不能使用传统的分布式事务（JTA/Raft等两段提交PC），这种情况下解决

OpsGenie是一家DevOps管理工具公司，我们在人员和产品功能方面一直在积极发展。去年我们的工程团队从15个增长到了50个。为了扩大开发团队，我们通过遵守双比萨团队规则将工程力量分为八人一个团队。 目前我们的产品有点庞大。团队实现并行开发工作，使用C

大部分公司迁移到微服务架构面临的一个挑战是如何实现微服务之间的通信。 在过去单体架构中，各个组件都在同一个进程中运行，相互通信只是相互的函数的调用而已。但是在微服务环境中，组件之间是由服务器硬性边界分隔了，一般位于不同的VM或JVM或服务器中，相互之间需要

Piotr Kononow是一位业务分析师、软件架构师和项目经理，他拥有15年以上编程经验和背景（SQL，java，C++…）。他的专长是数据仓库/ BI和商业应用，这是他的一篇文章： 最近我和几位DBA和架构师争论，他们对一些数据库没有外键感到震惊，并声

本文是讨论微服务和领域事件架构下一些需要长时间运行服务的设计问题，这些长时间运行的服务任务是因为有人工流程介入导致，比如请假需要所在部门和人事部门等两个部门领导批准，那么请假这个服务就可能需要一两天时间才能完成，因为需要两个部门领导都在电脑前且点按了批准按钮，这个请假服务流程才结束。

本文是Dave Kerr发表的一篇微服务批判性文章，他认为复杂性是导致微服务将死的一个重要原因，实际上微服务本来是解决复杂性的，将牵一动百的单体架构变成很多独立发展的服务，相互隔离，复杂性关键是因为隔离不清还是现实世界根本无法隔离分清或者没有能力去隔离？其实单体系统最大问题是单点风险，而微服务化解了

你的微服务是否太小？或者太紧密耦合？本设计指南可以提供帮助。 设计微服务往往更像是一门艺术而不是科学。本文提出五个建议： 1.它不会与其他服务共享数据库表2.它拥有最少量的数据库表3.它设计为有状

在讨论分布式系统的弹性之前，让我们快速回顾一些基本术语：弹性Resiliency：任何系统从困难中恢复的能力，(banq注：弹性也就是适应能力)。分布式系统：一些网络组件通过传递消息来完成一个共同目标。可用性：任何系统在任何时间点保持正常运行的可能性。故障与故障：故障

现在SOA架构下的服务管理面临很多挑战，比如面临一个非常大型的代码库，版本合并困难，甚至存在不同项目不同版本，维护量极其庞大，无法快速响应不同的业务需求；同时这些大型代码库由于没有前后端分离，导致打包成一个大型的WAR包，服务自身无法独立打包部署，在运行阶段，随着项目应用规模扩大无法平滑伸缩，只能通

本文是开源工作流引擎Camunda联合创始人Rücker对微服务调用进行弹性设计的改进建议，类似谷歌的gRPC和阿里的Dubbo都可以看成是RPC微服务，Spring提供了REST服务，这些服务虽然形式不同，本质都是同步调用。这种同步调用在生产环境可能遭遇各种意外情况发生堵塞延迟，怎么办？下面他提出

本文从单体和微服务这两个名词引申出二元论。二元论是一种非黑即白的对立思维，这种二分法会把现实问题扭曲。 当我们在学习微服务时，几乎总是会引入单体(巨石monolith)的概念。这里面存在一个伪装二分法（矛盾论）：如果你用的不是微服务，那你就是在用单体；如果

流媒体平台SoundCloud在2014年从SOA切换到微服务架构以后，几年经验证明其软件开发交付速度和生产力都有所提高。 遥想当初2014年，流行音乐和播客的流媒体平台SoundCloud变成自己成功的受害者。当时，用户每分钟都会上传12小时的音乐，每天

这是一篇提供如何从单体大型应用迁移到微服务+事件溯源的指导性文章，文章提供了六条建议，主要是确定微服务边界，将事件作为首要设计，将系统从过去面向接口的耦合变成面向事件数据的耦合，从而大大地增加微服务的独立性和灵活性，同时为性能的弹性扩展提供了可能。所谓面向接口耦合，就是你事先设计几个接口，定义其中的

任何拥抱Docker或Kubernetes等容器技术的人都毫无疑问听说过相关的下一件大事：服务网格，它承诺将微服务之间的内部网络通信同质化，并提供可观察性和容错性等非功能性特点。但是，支持服务网格的底层代理技术也可以在系统边缘提供 - 特别是在API网关内。

服务网格是一种使微服务之间通信更安全、更快速且更可靠的专用基础架构层。如果您正在构建云应用程序，那么你就需要一个服务网格。 在过去的一年中，服务网格已经成为云技术栈中的关键组件。Paypal，Ticketmaster和Credit Karma 等高流量公司

Linkerd是一种透明的服务网格service mesh，它与Istio一样，能够透明地统一管理服务间的通信，可以添加服务发现，负载平衡，故障处理，测量和路由等通讯功能. Linkerd（代号为“linker-DEE”）可以担当透明的HTTP / gRP