大厂必面的微服务架构，你了解多少？

Java海
269 阅读8分钟

前言

今天跟大家聊聊什么是微服务，自马丁 福勒（ Mattin Fow ler ）在 2014 年发表了以“微服务”为主题的文章后，微服务随之变得炙手可热 短短数年间，受到无数人的追捧 微服务架构不仅涉及架构设计和开发阶段，还包含了测试、部署以及运维阶段，是一个完整的生命周期，微服务已经是架构的一部分 作为有追求的开发人员和架构师，很有必要了解微服务的点点滴滴，现在基本上所有的大厂都是必面微服务的，很多人被问起也只会说：微服务架构是一种方法，其中单个应用程序由许多松散耦合且可独立部署的较小服务组成，总的来说就是只会一些皮毛，而且特别乱，没有体系。

让你详细说说微服务的时候就不知道该怎么回答了，为了避免大家面试的时候支支吾吾说不出个所以然来，在这里给大家整理了一份完整的资料，助力各位在即将到来的秋招拿下自己心仪的offer！

目录：

image.png

对这份微服务感兴趣想要获取的朋友可以点进去了解一下，点击——【传送门】——即可。

微服务的设计与运行

什么是微服务应用

微服务应用是 系列自治服务的集合，每个服务只负责完成一块功能，这些服务共同合作来就可以完成某些更加复杂的操作。

image.png

微服务的挑战

微服务并不是唯一通过分解和分布式实现“涅架”（解决一切麻烦）的架构模式，但是过去的一些尝试（如 SOA ）已经被大家认为是不成功的 没有哪一种技术是“银弹”，比如，我们提到的微服务架构，就极大地增加了系统中运行的模块的数量 在将功能和数据所有权分发到多个自治的服务上的同时，开发者也将整个应用的稳定性和安全操作的责任分配到了这些服务上。

image.png

微服务应用的架构

服务层

服务层，正如其名称所描述的一一它就是服务所存在的地方 在这一层，服务通过交互完成有用的功能一一这依赖于底层平台对可靠的运行和通信方案的抽象，常见的模式：业务和技术功能、聚合和多元服务以及关键路径和非关键路径的服务。

image.png

服务边界

边界层隐藏了内部服务的 杂交互，只展示了 个统一的外观 像移动 pp 、网页用户界面或者物联网设备之类的客户端都可以和微服务应用进行交互 （这些客户端可以是自己进行开发的，也可以由消费应用的公共 API 的第三方来开发

image.png

新功能设计

SimpleBank的新功能

SimpleBank 公司发现大部分客户并不想由他们自己来选择投资产品，而更愿意让 SimpleBank公司来替他们做这份苦差事 ，在微服务应用中找出个解决这问题的办法。

image.png

处理不确定性

划分微服务不仅是一门科学，还是一门艺术 软件设计的很大一部分内容就是在面对不明确的状况时， 找到一种有效的方法来获得最佳解决方案

image.png

微服务的事务与查询

基于事件的通信

使用服务发出的事件消息作为通信途径的方案 异步事件能够帮助我们解除服务之间的耦合和提高系统整体的可用性，但是这也促使服务的开发者开始思考最终一致性 eventual consistency 在采用最终一致性方案的系统中，开发者可以设计从多个独立的本地事务生成的复合型结果，这就需要为下层的各个资源明确设计各种暂时的状里克·布鲁尔（ Eric Brewer ）的 CAP 理论的角度看，这种设计方案将底层数据的可用性放在第一位。

image.png

设计高可靠服务

设计可靠的通信方案

在前面，我 强调了微服务中协作的重要性 多个服务相五依赖最终才 完成应用中最有价值的功能 一个微服务出现故障，会对协作方以及应用的最终用户产生怎样的影 呢？如果故障是不可避免的，那么在设计和开发服务时，我们要尽可能 提高服务的可用性和运行的正确性 以及在发生故障以后快速恢复的能力，这对于实现服务的可靠恢复是至关重要的。

image.png

构建可复用的微服务框架

微服务底座的目的

微服务底座的目的是简化服务的创建过程，同时确保开发者拥有一套所有服务都要遵循的标准，而不管哪个团队负责相应的服务 我们看看采用微服务底座的一些优点

( 1 ）让新加入的团队成员更容易上手

( 2 ）不管团队使用哪种技术支撑，都能很好地理解代码结构和关注内容

( 3 ）随着团队共同的知识越来越丰富，生产环境的试验范围得到控制，即使这些知识并不总

采用相同的技术拢

image.png

微服务部署

部署的重要性

在软件系统的生命周期中，部署是风险最大的时刻 和现实世界最贴切的类比就是换轮胎一一而且这辆车还在以约 160kn/h的速度飞驰着 没有哪个公司能够不受这一风险的影响：比如Goog 的网站可靠性（ site reliability ）团队认为大概有 的服务不可用是由于对生产环境的修改导致的微服务极

image.png

基于容器和调度器的部署

集群部署

容器调度器是一种软件工具，它通过管理共享资源池的不可拆分的、容器化应用程序的执行来将底层主机概念抽离出去 这是可能的，因为容器提供了强大的资源隔离功能以及一致性 API对于微服务来说，调度器是一个引人注目的部署平台，因为它在理论上简化了对任意数量的独立服务的伸缩扩容、健康检查和发布的管理 它在确保有效利用底层基础设施的同时做到了这一点。从整体来看，容器调度程序工作流的工作过程如下所

image.png

构建微服务交付流水线

让部署变得平淡

软件部署应该是平淡的 开发者应该能够将所做的变更或者新功能推出去，而不会出现心里战战兢兢却又祈祷一切顺利或者死死盯着监控界面以防出现错误的情况218服务交付流水线遗憾的是，人为错误是生产环境中大部分问题的主要源头，而微服务部署更是有太多的机会可以导致人为错误 体考虑，

团队按照自己的进度开发和部署数十个（假设还没达到数百个）独立服务，而团队之间没有任何明确的协调或者协作 那么对服务的任何一次不太好的修改都可能会对其他服务和整个应用的执行产生大范围的影响理想的微服务部署流程应该满足两大目标 一， 节奏安全一一新服务和变更的部署速

image.png

构建监控系统

稳固的监控技术栈

稳固的监控技术枝可以让开发者开始收集来自基础设施和微服务的度量指标，井使用这些度量指标加深对系统运行的理解 这个技术技应该提供一套收集、存储、展示和分析数据的方法

image.png

使用日志和链路追踪了解系统行为

了解服务间的行为

在基于微服务的架构中，提供给用户的功能会涉及多个不同的服务 在一个不具备中心化的人口统一访问数据时，我们很难了解 知道请求的执行情况 这些服务器临时性地分布在不同的服务器节点上，并且为了满足运行的需要 被反复地部署和扩容。

image.png

微服务团队建设

微服务团队的实践建议

微服务应用的变动规模可能是巨大的 事实上所有变化可能是很难的 期望所有 程师都能够深入了解所有服务及其交互方式是不合理的，特别是这些服务的拓展 结构可能在没有任何的情况发生了变化 同样，将人员分配到独立的团队可能不利于形成全局视角 这些因素导致一些有趣的文 影响

image.png

对这份微服务感兴趣想要获取的朋友可以点进去了解一下，点击——【传送门】——即可。

avatar
文章
阅读
粉丝