微服务

? 研究发现，硬盘一般三年就坏 ? 从微服务转换到单体应用，减少了 90% 的成本 ? Mojo：一种具有 C 语言速度的 Python 超集 » »

微服务遵循领域驱动设计（DDD），与开发平台无关。Python 微服务也不例外。Python3 的面向对象特性使得按照 DDD 对服务进行建模变得更加容易。

在微服务环境中，服务网格为开发和运营提供了好处。

通过这三个工具和框架，为你的企业级 Java 应用和你的职业生涯提供助力。

本文将帮助你了解什么是微服务，以及目前的公司如何使用它的。

在问题导致关键的微服务瘫痪之前，使用 GraphQL 的监控功能帮助你及早发现问题。

顶级 CTO 基于五个简单的原则为精心设计的微服务提供建议。

微服务是个好东西，就像乐高积木一样，你可以拼成各种东西，当前，前提是你足够会玩。

从早些年的 SOA 和中间件，到现在的微服务和容器，但似乎历史总是螺旋式变化的。看起来笨拙而大而无当的独石应用，其实在很多场景，要比微服务更适合。

在现代微服务环境中，构建小型、单一的应用程序的旧策略又再一次流行了起来。

如果我告诉你有这样一种软件架构，一个应用程序的组件通过基于网络的通讯协议为其它组件提供服务，我估计你可能会说它是 …

任何一种架构都是有利有弊的，而能满足你组织的独特需要的决策才是正确的选择。

你可能并不想把所有的遗留应用全部分解为微服务，或许你可以考虑从安全功能开始。

因为微服务和容器是 天生的“一对”，所以一起来使用它们，似乎也就不会有什么问题。当我们将这对“天作之合”投入到生产系统后，你就会发现，随着你的 IT 基础的提升，等待你的将是大幅上升的成本。是不是这样的？

由于这种方法从根本上改变了软件的构建、部署和运行方式，它也从根本上改变了软件需要保护的方式。云原生程序和基础架构为安全专业人员带来了若干新的挑战，他们需要建立新的安全计划来支持其组织对云原生技术的使用。

我希望这篇对各种策略和容器的深入剖析有助于你的公司对下一步进行评估。

• 监控容器及其里面的东西。
• 在服务性能上做监控，而不是容器性能。
• 监控弹性和多地部署的服务。
• 监控 API。
• 将您的监控映射到您的组织结构。

"微服务是一股新浪潮" - 现如今，将项目拆分成多个独立的、可扩展的服务是保障代码演变的最好选择。在 Python 的世界里，有个叫做 “Nameko” 的框架，它将微服务的实现变得简单并且强大。

可能对某些人来说这很简单，因为他们在运维工作方面付出了大量的时间。但是对我来说实际上是很困难的，但是还有一个好消息：我最终搞定了。而且它工作的还不错。所以我准备分享向你分享我如何制作我的第一个微服务容器。我的痛苦可能会节省你不少时间呢。