Docker 和 Kubernetes 为代表的容器技术炙手可热，熟知这一技术领域的用户，一定都知道下一个热点：Service Mesh，它承诺将微服务之间的内部网络通信均一化，并解决一系列监控、故障

前言 又是很久没写博客了，最近一段时间换了新工作，比较忙，所以没有抽出来太多的时间写给关注我的粉丝写一些干货了，就有人问我怎么最近没有更新博客了，在这里给大家抱歉。 那么，在本篇文章中，我们就一起来探

本文是来自于Macro在一次大会上的一个分享。 本系列共有两个部分，主要关注我们如何以及为什么要在我们的微服务应用中部署API 网关。第二部分主要关注我们如何把Mashape的开源网关组件Kong运用

通常情况下，一个新版本发布时，开发人员会将软件新版本发布到开发环境中进行自测，待到自测完成后，再在测试环境中发布一个新版本，最后通知测试人员进行测试。而在测试环境的发布过程中，开发人员和测试人员的沟通

非常巧合，2013 年 3 月 Docker 发布 0.1 版本，时隔一年（2014 年 3 月）Martin Fowler 给出了微服务架构的定义。经过几年的发展，两个毫不相干的技术最终走到了一起：

随着微服务架构的推广，越来越多的公司采用微服务架构来构建自己的业务平台。就像前边的文章说的，微服务架构为业务开发带来了诸多好处的同时，例如单一职责、独立开发部署、功能复用和系统容错等等，也带来一些问题

前面的文章中有说到微服务的通信方式，Martin Folwer 先生在他对微服务的定义中也提到“每个服务运行在其独立的进程中，服务与服务间采用 轻量级的通信机制 互相协作（通常是基于 HTTP 协议的

  记得好久之前看到一个大牛说过：如果单体架构都搞不好，就别搞微服务架构。乍一看，这句很有道理，后来发现这句话是不太对的，因为微服务架构的目的就是为了降低系统的复杂性，所以 微服务架构应该比单体架构更

导语 虽然已经红了很久，但是“微服务架构”正变得越来越重要，也将继续火下去。 各个公司与技术人员都在分享微服务架构的相关知识与实践经验，但我们发现，目前网上的这些相关文章中，要么上来就是很有借鉴意义的