微服务架构实践 - 你只懂docker与spring boot就够了吗？

背景

随着公司一年多的成长，我们已经开发了数十个项目了，后台有JAVA的有PHP的，为了更好地提升开发与管理效率，各技术大牛小牛们时常进行激烈的PK，碰撞出了许许多多爱的火花，比如其中之一：微服务实践

设计

只需要有一套BASE微服务，BASE微服务生成业务系统微服务实例，供各个业务系统调用；业务系统不直接调用BASE，只能调用微服务INSTANCE。

这是运维的问题，让运维去解决，运维使用工具，实际也不算困难，反正执行的都是脚本，不需要手工 *** 作。

单点故障影响全局，我们选择了稳定更重要；另外saas的话，为了应对不同行业，会存在过度设计的嫌疑；私有化更容易。

调用逻辑

设计理念

非模块化，谈不上微服务，比如我们上面的用户微服务、产品微服务、地址微服务等，都需要先模块化，为了更好地落实开发，你可能不得不，边模块化边微服务，模块化的时候要注意，不能有关联查询，包要完全独立，到时候微服务才能拆开。

松耦合表示我们模块之间不直接依赖，无状态，可以单独地为外界提供服务；

强内聚是指，我们虽然要拆分成一个个小的微服务，但是也要考虑某些功能的强关联性，比如一个凳子是由四个脚与一个板组成，我们不能把四个脚与板分开售卖，就没有意义了。

开发

spring-boot :较springmvc更加简约了，springmvc有一大零的配置文件，比如spring-servlet、spring-mybatis、springxml与webxml，这些在spring-boot都不需要了，只需要强大的注解功能即可，boot更合适微服务。

spring-cloud :里面有比较多组件，用于支持微服务，比如spring cloud config统一配置中心，用于多环境的配置文件配置，大家再也不用为多个微服务的开发、测试与生产环境的配置文件管理而发愁了；spring cloud eureka用于服务注册与发现，下面有单独介绍；其它的组件大家可以去官网看看，这里不一一介绍，总之如果JAVA平台，尽量使用spring体系的内容。

我们采用mysql，因为我们是应用多，但数据量单表并不算大，多则不超过百万，mongodb也实验过，开发非常快，也非常灵活，但因为不是关系型数据库，维护成本较高。

RESTFUL ：URL的资源与 *** 作解耦，让URL更加符合语义，上百个接口也非常好管理，网上有很多文章讲得非常透彻，这玩意不是特别好理解，要多领悟，在项目中实践，就有矛塞盾开的感觉，这里不做详细介绍。

接口文档swagger ：比起传统全手工写接口文档，swagger有统一的输出格式，不管是几个人写的；swagger采用写代码的方式来写接口文档，以前修改了代码，还必须打开wiki手工修改接口文档，现在只需要修改一下代码即可，程序员更愿意修改了，成本更低了，前端与其它调用者不会天天吼着，你这接口咋又变了，新加的字段是啥意思呀。

RocketMQ：一直纠结kafka与rocketMQ，最终选择了RocketMQ

为了性能上面的考虑，尽量使用异步编程，比如注册送优惠券，那么注册成功就可以给用户返回注册成功了，但是送优惠券可以是异步调用的，不阻塞注册的线程。

微服务框架下，日志不可能还分散在各个服务节点上，必须有统一的日志中心。ELK是一个实时日志分析平台，就是将各个服务的日志汇总于日志中心，然后可以按照系统、节点等进行搜索，除上述搜索条件外，我们还在各个微服务实现了按照业务id（一次请求生成一个业务id）与用户id搜索日志，方便跟踪与定位问题。

当然可能有更加轻量级与好用的disconf或spring cloud config，但是我们有php开发的应用，以上二者都不支持。如果全是JAVA应用，采用disconf还是非常不错的。

测试

每个程序员都有这样的经历，刚上线，客户又反馈了bug，原来是我们修改某个功能代码的时候，导致了其它功能的bug，每次上线心里都没底；这就体现了接口测试的必须性，尤其是每次版本升级的时候，都需要执行一遍，以防修改某个接口导致其它接口报错，比手动测试靠谱许多。

部署

docker已经家喻户晓了，这是继虚拟机以后，又一重大变革，将所有的单个微服务都放在docker中，这样你何时何地想部署，直接丢过去就OK了，快到爆。

用几句简单的命令就搞定了负载均衡，而且还可以平滑升级，版本升级的时候，大家就不用告诉客户：系统通知，某日某晚00:00-08:00我行处于系统升级维护中，大家不要去取钱哦，因为你可能取不出来，呵呵。

升级

我们采用工具flyway，可以对数据库脚本进行版本控制。

传统的版本升级，

1开发推代码并同时记录自己提交了哪些文件；

2项目经理根据svn审核文件，并打包成war包；

3投到测试环境让测试公司测试；

4中途修改了文件，可能需要重新打包；

…

我都写不下去了，项目经理像个超人似的。

现在用持续集成（CI）非常简单，我们用的工具是Jenkins，推完代码，点几下按钮就完成了上线，不管是测试环境，还是生产环境都非常简单，不然项目经理核对文件眼睛都绿了。

结尾

本文主要是介绍微服务开发上的选型，对于细则不做深究，大家感兴趣可以了解下各个组件。当然，我们的选型未免正确，不同场景应用可能完全不同，本文仅供参考。

异常的三种场景：

1、服务僵死，微服务发生OOM之类的错误，导致微服务无法继续提供服务

2、服务性能差，微服务内部事务处理慢，导致大量CloseWait连接

3、服务异常，节点事务处理失败比率太高

三种场景的运维监控：

第一种，监控日志OOM错误、监控JVM内存使用情况（jstat）指令

第二种，监控网络连接CloseWait状态连接数，超出一定的比率，该节点评估为问题节点，监控事务处理日志，如果大量超出预期，判定为问题节点

第三种，统计事务处理日志，应用错误类型的事务失败的比率统计，超出容忍则判定为失败节点

三种场景的运维处理：

Step1、隔离微服务，一旦判定为失败节点立即隔离该微服务，SpringCloud直接修改该微服务在Eureka中的状态即可 curl -X PUT >

微服务架构对于程序员来说是需要掌握的新型技术之一，而其受到追捧的原因就是符合互联网的发展以及其便捷性。今天我们就一起来了解一下，微服务架构带来的变化。

微服务架构给IT系统和团队带来了以下显著的变化：

基础设施的升级，需要引入虚拟化(如Docker)，现存基础设施也需要与之进行适配;

系统架构的升级，需要引入服务注册(如Consul)，服务间的交互方式也需要与之进行适配;

运维平台的升级，建议引入日志收集(如Fluentd)，分布式跟踪(如Zipkin)和仪表盘(如Vizceral/Grafana)等;

运维效率和自动化水平的提升也迫在眉睫，否则无法应对实例数量，变更频率，系统复杂度的快速增长;

观念的转变，基础设施，系统架构和运维平台等的大幅升级，犹如小米加步q换成飞机大炮，相应的战略战术也需要与之相适配才行。

微服务架构下用户面临的监控问题

在转型到微服务架构以后，用户在监控方面主要会面临以下问题。

监控配置的维护成本增加。某个在线系统大概有106个模块，每个模块都需要添加端口监控，进程监控，日志监控和自定义监控;不同服务的监控指标，聚合指标，报警阈值，报警依赖，报警接收人，策略级别，处理预案和备注说明也不完全相同;如此多的内容，如何确保是否有效，是否生效，是否完整无遗漏。

当前针对维护成本，业界常用的几种方法有：

通过变量的方式尽量减少人工输入;

通过监控配置文件解析做一些可标准化的校验;

通过故障演练验证报警是否符合预期;

其次，三方依赖越来越多。北京电脑培训发现例如Docker的可靠性很大程度上取决于宿主机，如果所在的宿主机发生资源争用，网络异常，硬件故障，修改内核参数， *** 作系统补丁升级等，都可能会让Docker莫名其妙地中招。

微服务¹架构的目标是帮助工程团队更快，更安全，更高质量地交付产品。解耦服务允许团队快速迭代，对系统的其余部分影响最小。

在Medium，我们的技术堆栈始于2012年的单片Nodejs应用程序。我们已经构建了几个卫星服务，但我们还没有制定一个系统地采用微服务架构的策略。随着系统变得越来越复杂并且团队不断发展，我们在2018年初转向了微服务架构。在这篇文章中，我们希望分享我们有效地做到这一点并避免微服务综合症的经验。

首先，让我们花一点时间来思考微服务架构是什么，不是什么。 “微服务”是那些过载和混乱的软件工程趋势之一。这就是我们在Medium认为它是什么：

该定义包括三个微服务设计原则：

Three Principles of Modeling Microservices

当我们对微服务进行建模时，我们应该遵守所有三个设计原则。这是实现微服务架构全部潜力的唯一途径。错过任何一个都会成为反模式。

没有一个目的，每个微服务最终会做太多事情，成长为多个“单片”服务。我们不会从微服务架构中获得全部好处，我们也会支付运营成本。

如果没有松散耦合，对一个服务的更改会影响其他服务，因此我们无法快速安全地发布更改，这是微服务架构的核心优势。更重要的是，紧密耦合引起的问题可能是灾难性的，例如数据不一致甚至数据丢失。

如果没有高凝聚力，我们将最终得到一个分布式单片系统 - 一组混乱的服务，必须同时进行更改和部署才能构建单一功能。由于多个服务协调的复杂性和成本（有时跨多个团队），分布式单片系统通常比集中式单片系统差得多。

与此同时，了解 微服务不是什么 很重要：

在Medium，我们总是在做出重大产品或工程决策时会问“为什么现在？”这个问题。 “为什么？”是一个显而易见的问题，但它假设我们拥有无限的人，时间和资源，这是一个危险的假设。当你想到“为什么现在？”时，你突然有了更多的限制 - 对当前工作的影响，机会成本，分心的开销等等。这个问题有助于我们更好地优先考虑。

我们现在需要采用微服务的原因是我们的Nodejs单片应用程序已经成为多个方面的瓶颈。

首先，最紧迫和最重要的瓶颈是其性能。

某些计算量很大且I / O很重的任务不适合Nodejs我们一直在逐步改进整体应用程序，但事实证明它是无效的。它的低劣性能使我们无法提供更好的产品而不会使已经非常慢的应用程序变慢。

其次，整体应用程序的一个重要且有点紧迫的瓶颈是它会减慢产品开发速度。

由于所有工程师都在单个应用程序中构建功能，因此它们通常紧密耦合。我们无法灵活地改变系统的一部分，因为它也可能影响其他部分。我们也害怕做出重大改变，因为影响太大，有时难以预测。整个应用程序作为一个整体进行部署，因此如果由于一次错误提交导致部署停滞，那么所有其他更改（即使它们完全正常工作）也无法完成。相比之下，微服务架构允许团队更快地发货，学习和迭代。他们可以专注于他们正在构建的功能，这些功能与复杂系统的其余部分分离。更改可以更快地进入生产。他们可以灵活地安全地尝试重大变革。

在我们新的微服务架构中，更改会在一小时内完成生产，工程师不必担心它会如何影响系统的其他部分。该团队还 探索 了在开发中安全使用生产数据的方法²多年来一直是白日梦。随着我们的工程团队的发展，所有这些都非常重要。

第三，单一应用程序使得难以为特定任务扩展系统或隔离不同类型任务的资源问题。

使用单一的单一应用程序，我们必须扩展和缩小整个系统，以满足更多资源需求的任务，即使这意味着系统过度配置用于其他更简单的任务。为了缓解这些问题，我们对不同类型的请求进行分片，以分离Nodejs进程。它们在一定程度上起作用，但不会扩展，因为这些微单一版本的单片服务是紧密耦合的。

最后但同样重要的是，一个重要且即将成为紧迫的瓶颈是它阻止我们尝试新技术。微服务架构的一个主要优点是每个服务都可以使用不同的技术堆栈构建，并与不同的技术集成。这使我们能够选择最适合工作的工具，更重要的是，我们可以快速安全地完成工作。

采用微服务架构并非易事。它可能会出错，实际上会损害工程生产力。在本节中，我们将分享七个在采用早期阶段帮助我们的策略：

有人可能会认为采用新的服务器架构意味着产品开发的长时间停顿以及对所有内容的大量重写。这是错误的做法。我们永远不应该为了建立新的服务而建立新的服务。每次我们建立新服务或采用新技术时，都必须具有明确的产品价值和/或工程价值。

产品价值应以我们可以为用户提供的利益为代表。与在单片Nodejs应用程序中构建值相比，需要一项新服务来提供值或使其更快地交付值。工程价值应该使工程团队更好，更快。

如果构建新服务没有产品价值或工程价值，我们将其留在单一的应用程序中。如果十年内Medium仍然有一个支持某些表面的单片Nodejs应用程序，那就完全没了问题。从单一应用程序开始实际上有助于我们战略性地对微服务进行建模。

建立具有明确价值的新服务

有人可能会认为采用新的服务器架构意味着产品开发的长时间停顿以及对所有内容的大量重写。这是错误的做法。我们永远不应该为了建立新的服务而建立新的服务。每次我们建立新服务或采用新技术时，都必须具有明确的产品价值和/或工程价值。

产品价值应以我们可以为用户提供的利益为代表。与在单片Nodejs应用程序中构建值相比，需要一项新服务来提供值或使其更快地交付值。工程价值应该使工程团队更好，更快。

如果构建新服务没有产品价值或工程价值，我们将其留在单一的应用程序中。如果十年内Medium仍然有一个支持某些表面的单片Nodejs应用程序，那就完全没了问题。从单一应用程序开始实际上有助于我们战略性地对微服务进行建模。

单片持久存储被认为是有害的

建模微服务的很大一部分是对其持久数据存储（例如，数据库）进行建模。跨服务共享持久数据存储通常似乎是将微服务集成在一起的最简单方法，然而，它实际上是有害的，我们应该不惜一切代价避免它。这就是原因。

首先，持久数据存储是关于实现细节的。 跨服务共享数据存储会将一个服务的实现细节暴露给整个系统。如果该服务更改了数据的格式，或者添加了缓存层，或者切换到不同类型的数据库，则还必须相应地更改许多其他服务。 这违反了松散耦合的原则。

其次，持久数据存储不是服务行为，即如何修改，解释和使用数据 。如果我们跨服务共享数据存储，则意味着其他服务也必须复制服务行为。 这违反了高内聚的原则 - 给定域中的行为泄露给多个服务。如果我们修改一个行为，我们将不得不一起修改所有这些服务。

在微服务架构中，只有一个服务应该负责特定类型的数据。所有其他服务应该通过负责服务的API请求数据，或者保留数据的 只读非规范（可能具体化）副本 。

这可能听起来很抽象，所以这是一个具体的例子。假设我们正在构建一个新的推荐服务，它需要来自规范帖子表的一些数据，目前在AWS DynamoDB中。我们可以通过两种方式之一为新推荐服务提供发布数据。

在单片存储模型中，推荐服务可以直接访问单片应用程序所执行的相同持久存储。这是一个坏主意，因为：

缓存可能很棘手。 如果推荐服务与单一应用程序共享相同的缓存，我们也必须在推荐服务中复制缓存实现细节;如果推荐服务使用自己的缓存，当单片应用更新帖子数据时，我们将不知道何时使其缓存无效。

如果单片应用程序决定更改为使用RDS而不是DynamoDB来存储帖子数据，我们将不得不重新实现推荐服务中的逻辑以及访问帖子数据的所有其他服务。

单片应用程序具有解释帖子数据的复杂逻辑 ，例如，如何确定帖子是否应该对给定用户不可见。我们必须在推荐服务中重新实现这些逻辑。一旦整体应用程序更改或添加新逻辑，我们也需要在任何地方进行相同的更改。

即使推荐服务是自己的数据访问模式的错误选项，推荐服务仍然停留在DynamoDB上。

在解耦存储模型中，推荐服务不能直接访问发布数据，也不能直接访问任何其他新服务。发布数据的实​​现细节仅保留在一个服务中。有不同的方法来实现这一目标。

Option A 理想情况下，应该有一个拥有帖子数据的Post服务，其他服务只能通过Post服务的API访问邮政数据。但是，为所有核心数据模型构建新服务可能是一项昂贵的前期投资。

当人员配置有限时，还有一些更实用的方法。根据数据访问模式，它们实际上可能是更好的方式。

在 选项B 中，单一应用程序可让推荐服务知道何时更新相关的帖子数据。通常，这不必立即发生，因此我们可以将其卸载到排队系统。

在 选项C 中，ETL管道生成推荐服务的发布数据的只读副本，以及可能对推荐有用的其他数据。在这两个选项中，推荐服务完全拥有其数据，因此它可以灵活地缓存数据或使用最适合的数据库技术。

解耦“建立服务”和“运行服务”

如果构建微服务很难，那么运行服务往往更难。 当运行服务与构建每个服务相结合时，它会减慢工程团队的速度，团队必须不断重新发明这样做。我们希望让每项服务都专注于自己的工作而不用担心如何运行服务的复杂问题，包括网络，通信协议，部署，可观察性等。服务管理应该与每个服务的实现完全分离。

由于最近在 容器化，容器编排，服务网格，应用程序性能监 控等方面的技术进步，“运行服务”的解耦变得比以往更容易实现。

网络。 网络（例如，服务发现，路由，负载平衡，流量路由等）是运行服务的关键部分。传统方法是为每种平台/语言提供库。它工作但不理想，因为应用程序仍然需要非常繁琐的工作来集成和维护库。通常，应用程序仍然需要单独实现某些逻辑。现代解决方案是在Service Mesh中运行服务。在Medium，我们使用 Istio和Envoy作为边车代理 。构建服务的应用工程师根本不需要担心网络问题。

通信协议 。无论您选择哪种技术堆栈或语言来构建微服务，从一个高效，类型化，跨平台且需要最少开发开销的成熟RPC解决方案开始是非常重要的。支持向后兼容性的RPC解决方案也使部署服务更加安全，即使它们之间存在依赖关系。在Medium，我们选择了gRPC。

一种常见的替代方案是基于>