导读：微服务是一个模糊的术语，通常指的是小型独立服务，共同组成一个应用程序。 微服务架构与单片架构相反，其应用程序是一个大系统。 我们将讨论如何开始作为初学者，并选择正确的工具来建立微服务架构。
迅速崛起的微服务
根据Google趋势指数的结果，近来微服务已经越来越流行：
在开始认识之前，我们先来了解为什么微型服务器正在普及，即使它不是一个新的概念。这可以通过康威定律来解释：
设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。
为什么是微服务
技术栈中妥协更少
技术栈的选择总是一个艰难的任务，团队的技能，可扩展性，可维护性都是这一选择的重要因素。但是很多时候对应用程序的一部分有好处，对其他部分来说却是不好的。
例如，交易平台由于支持交易而需要 PostgreSQL，而用户特定的数据必须存储在 DynamoDB中，一般来说，这就需要做出妥协。但是在微服务体系结构中，每个微服务器都以其最佳形式拥有一组业务逻辑和相关数据，并提供一个与之交互的界面。因此，可以为 PostgreSQL 和 DynamoDB 托管的数据提供交易和用户的微服务，只允许通过该接口访问外部服务。 因此，计算密集的微服务可以用 Python 编写，而 API Server 保留在 NodeJS 中，依此类推.
示例架构如下所示
团队独立
在一个单一的应用程序中，开发团队中的大多数人，即使开发一个小功能都需要知道应用程序的所有部分。他们必须与其他团队在部署计划，版本控制，数据迁移等方面进行合作。另一方面，在微服务架构中，团队只需要知道其他服务提供的界面，并坚持其所提供的界面，每个微服务应该是独立部署的。像 CirclCi，Travis 和 Heroku 这样的 CI/CD 工具在开发微服务时都非常有帮助，要开发/维护一个服务，一个小团队就足够了。
只做一件事，并把它做好
微服务架构也类似于 Unix 哲学的原则，做一件事，把它做好。 这是一个被证明很有价值的原则，也是几十年之后 Unix 系统也不会过时的原因之一。 微服务应设计为做一件事，经过测试以处理所有可能的情况，然后通过 “管道” 形成一个健壮和灵活的应用程序。
故障隔离
想象一下「报告生成」模块中的错误，将整个交易应用程序关闭，这是可怕的和不必要的。 如果应用程序基于微服务器，则「报告生成」模块将失败，只占用该特定功能。 没有生成报告的用户甚至不会注意到，应用程序的关键部分仍然可以工作。 这是微型服务器之间松散耦合的结果，现在可以通过这种架构实现。
怎么开发微服务
在Node.js中，Seneca是开发微服务的广泛使用的框架。但如果你想深入参与，请继续阅读。
API 网关
微服务可以在没有主要的中央服务的情况下进行部署，但是有时中间层通常会保留共享库，有时它也可以作为一个 API 网关。API 网关用于向客户端提供一致的 API，而不管后端服务如何，反之亦然。当您拥有适合移动，web，其他服务器等客户端的多种微服务时，这是很有帮助的。此外，它可以阻止客户端通过将其抽象为一个请求来向多个服务发出请求。
业务间通信
这些服务应该如何相互通信？well，有很多选择。
- HTTP：最直接的是使用 HTTP/HTTPS，并且接口可以作为 RESTful API。尽管如此，HTTP 使服务发现变得困难而且动态不足。这是我不喜欢的原因。
- 消息队列：诸如 AMQP，STOMP 和 MQTT 之类的消息队列协议允许使用发布订阅模式来进行微服务之间的通信，像 RabbitMQ 和 Apache Kafka 这样的服务被广泛用于这个目的。我个人更喜欢使用消息队列，因为它们是容错的，并支持消息持久性。
microservice-template 是我们在基于 Microservices 的项目中使用的基本样板。它在 Node 中，并将 MongoDB 配置为数据存储。它通过 servicebus 接到 RabbitMQ 进行业务间通信，这是它的最低限度的外观：
还有其他概念，例如 Event Sourcing 和 CQRS ，它们补充了微服务架构。Event Sourcing 基本上是存储数据的变化，而不是数据的改变状态。 在高度并发的环境中，Event Sourcing 带来更高级别的一致性。
但是事实却是，微服务体系架构不是银弹，对于相当小的应用程序使用微服务可能导致生产力的损失，如上图所示。
原文： Microservices for beginners, how to get started with right tools | Codebrahma
欢迎关注：
有疑问加站长微信联系（非本文作者）
