整体式锯切故事通常看起来很相似。 该团队拥有笨拙的笨拙巨石，他们决定将其切成分散的常规和智能微服务，一切都变得很酷。 故事的不同之处仅在于恐怖的“前”，“后”的喜乐和许多次要特征。
在RBK.money，我们还提供微服务。 但是我们来到他们那里与大多数人有所不同。 对我们来说，所有事情都比整装待发还要糟糕-刚开始时，一切都很糟糕。
关于我们实际上是如何构建微服务的，为什么OpenSource不仅在原理上很棒，而且还是编写好的代码的激励因素。
所以，一切都不好。 如此之多以至于修复它没有任何意义，但是同意永不回想这种恐怖并仅仅从头开始编写所有内容是有道理的。 并立即使用微服务。 在开发的第一阶段，我们立即将一条规则牢记在心，即有一天我们将要重新感化所有这些优点或部分优点。 毕竟，所有内容都保存在提交历史中，包括开发人员的昵称，因此我们坐下来立即尝试编写所有内容，以免以后在社区面前对我们的代码感到羞耻。 毕竟，没有人愿意为自己的代码或项目的架构感到羞耻。
快与好
在理想的世界中，您总是想快速编写代码并编写得很好。 好吧，这就像“比穷人和病人更富裕和健康”。 因此，微服务已成为摆脱这种情况的绝佳方法。 编写代码的过程基于业务任务。 假设一家企业需要在付款时将交易对手帐户中的资金考虑在内的功能。 此功能变成了代号为Accounter的微服务，它用于记帐工具。 与其他微服务一样。
这里的主要目的是确保每个业务功能都具体化，以便一个人可以编写它。 这在很大程度上取决于要完成的任务本身，以及技术总监或项目如何将其转化为团队。 我们设法做到这一点，它立即带来了几个很好的显着优势。
首先，它提供了大量的开发并行化。 最初，我们大约有10个人，我们设法同时编写了大量代码（写得很好）。 其次，它使您有机会完全旋转。 但这已经比乍看之下要重要得多。
很多时候，一个人开始大便，不是因为他替你找到了这份工作，而是因为他的眼睛变得老旧而无聊又无聊。 如果一个人经常坐在同一微服务上，则可以开始生成govnokod。 这不仅仅是时间问题，而是专业性问题。 在7到8个月后，人们会厌倦支持相同的微服务，而他们会四处张望-生活就是这样，春天来了，冬天来了，我的同事们有了某种运动，又有一部新的iPhone出现了，你们都坐在同一微服务上。 这就是巨石诞生时出现单点故障的方式，这种疲倦的人眼中带着袋子。
或者，总的来说，一个人开始认为一切都在他身上，而一切都在他身上。 她将通过围绕一堆“秘密知识”和奇怪的程序来使自己的工作变得必不可少。 在旅途的开始，我曾遇到过这样的情况，即遗产如此疯狂，以至于没有这些知识就无法弄清楚。 例如，您必须启动一项服务。 正如您通常想象的那样：
- 启动服务。
怎么样：
- 转到Windows注册表。
- 在此处找到特定的密钥。
- 将其更改为1。
- 启动服务。
- 将键值重置为0。
出于复杂性的考虑，这是复杂性的经典示例，“没有我，在这里什么也做不了”。 实际上，没有这个，一切都会起作用。 只有更快更好。 您可以通过轮换摆脱这种情况-理想的情况是，一个人写了一个微服务大约两次冲刺，然后又去做另一项任务。 同样，我们支持团队中不断的知识交流。
协议中的代码
如果您从业务中获取任何传统知识，请将其很好地转化为人类的传统知识，摆脱外壳并蒸发掉-您将获得协议，即机器将与之通信的语言。 也就是说，我们承担一项业务任务，自己了解确切的内容以及我们将如何执行该任务，并将其转变为节俭或摇摇欲坠的规范（内部的微服务通过节俭进行通信）。 第一步是详细描述所有内容：微服务将执行的操作，它将接收的数据类型，将要回答的数据，将要构成的结构等等。 该协议将首先对那些清楚了解一切工作原理的人（事实上的架构师）进行审查。 它的作用就像一个粗略的过滤器，即使在概念层面，某些坦率的胡说也不会通过。
协议出现后，您就可以坐下来编写代码了。 如果该协议完全由通用人员自行修订，则代码本身将由一组特定人员组成。 我们用三种语言编写-JS，Java，Erlang。 最主要的是不要急于进行审查或编写代码的任何人。 是的，业务随时随地都需要快速而凉爽。 但是我很少急于担任技术主管，因为我知道他们想要做的很好。 结果是，随着时间的推移，我经常受到商业客户的鼓励。 但实际上不必为质量而脸红。
累积奖金时，我们只匆匆忙忙一次-超级客户和极其紧急的截止日期，才创建了我们的电子钱包。 然后，是的，我们放下袖子，做所有事情的速度都比我们计划的要快（而且比我们想要的要糟糕，是的）。 理想情况下，一切都被认为是一堆精巧的微服务。 事实证明，这样的巨石。 这种情况的好处是，我们再次认识到自己没有急事的必要。 而且，服务本身已经按照他们的意愿缓慢地引入了单独的微服务中。
RBK Money中有50种微服务，它们由大约20个人编写。 Thrift内部无处不在，对于开发人员来说，它是一个相当复杂的协议，难以使用基础知识，也很难编写文档。 如果我以最纯粹的方式节俭，他们会说我不好的话。 因此，我们什么也没想出来-剩下的JSON，简单直观，再加上OpenAPI，值得一提。 为了能够从外部接受这些请求，必须先对它们进行验证，授权，然后由其他微服务将其启动到平台中。 我们还把这件事写成一个独立的微服务，它是：
- 接受外部赃物；
- 验证方案；
- 授权用户；
- 将所有这些变成节俭的请求；
- 好吧，他当然会写日志。
在微服务上编写支付系统是否方便？ 当然-在这里您可以并行工作，并维护员工的利益，并且没有单点故障。 一个微服务崩溃了，或者昨天做它的人突然离开了-没问题，您可以快速修复一些问题，并在新冲刺期间将一个新人放到飞行员的座位上。
但是，有一种观点认为，如果一个人长时间坐着并仔细地切割特定的微服务，那他肯定做得很好。 自从我们开始谈论这一点以来，请在评论中写下哪种方法更接近您。 最重要的是-为什么。