timg.jpg

什么是微服务架构

• 说到微服务必须提到的两个人马丁福勒(Martin Flower)和克罗夫特(Adrian Cockcroft),马丁福勒在2014年在他的博客上写过一篇文章,介绍微服务架构
• 微服务架构的特点
  • 一组小的服务
    • 微服务架构主张
  • 独立的进程
  • 轻量级通信
  • 基于业务能力
  • 独立部署
  • 无集中式管理

架构师如何权衡微服务的利弊

• 微服务利
  • 强模块化边界
  • 可独立部署
  • 技术多样性
• 微服务弊
  • 分布式复杂性
  • 最终一致性
  • 运维复杂性
  • 测试复杂性

康威法则和微服务给架构师怎样的启示康威法则:是一个叫康威的人在1967年提出来的;设计系统的组织，其产生的设计等同于组织之内、组织之间的沟通结构。

• 康威法则和微服务的关系
  • 一个公司随着业务增加项目变大,需要多个团队协同工作,这时候如果项目还是一整块的,那么项目和团队就是不匹配.多个团多很多人在协同工作的时候沟通成本变高,协同效率变低;当某个团队在自己的业务部分有改动时需要其它团队配合,沟通成本是较高的,中间甚至会出现摩擦
  • 微服务解决了这个问题,我们把单块的应用拆解出来,拆分成多个微服务,每个团队负责维护自己的服务,相互之间互不干扰;这样某个团队或个人负责的部分交付的时候变得更加方便,不需要其它团队协同.这样多团队和多服务之间的联系变得清晰紧密,它符合了康威法则,整体的研发效率和业务支持变得更高效

企业应该在什么时候开始考虑引入微服务

• 企业应该在什么时间段引入微服务
  • 从生产力和项目复杂性来考虑,在开始项目的时候业务复杂性不高,用户量也不大,这时候我们应该优先考虑单块应用,不推荐微服务,因为微服务是有基础设施要求的,需要前期的投资,团队不大生成力也会降低;而随着项目越来越成功,用户量的增加,系统的复杂性也变高,这时候团队变得越来越大,就会出现团队规模与项目不匹配的情况,违反康威法则,生产力随着系统复杂性逐渐下降,这时候就该考虑引入微服务
• 项目架构设计一开始就设计微服务,还是做单块应用
  • 单块优先,项目一开始,你对项目问题不是很理解,跟难把控怎么来拆分服务,划分服务的边界,而且还未被客户验证,可能会失败;我们先做单块应用,随着业务不断扩展,团队规模不断扩展,你的项目业务架构越来越清晰,单块应用已经无法满足需求,研发效率开始下降,达到一个临界点,发现我们需要把某些个业务模块拆分出来,这样就慢慢变成一个微服务架构
• 好的架构是设计出来的还是演化出来的
  • 系统架构的目标是解决利益相关者的关注点。架构系统前架构师的首要任务是尽最大可能找出所有利益相关者;架构师常犯的错误就是漏掉利益相关者,沟通不充分,都会造成架构有欠缺,不能满足相关利益者的需求。架构是对一个系统起关键作用的设计决策，架构定系统就基本成型了。进一步说，架构的目标是用于管理复杂性、易变性和不确定性，以确保在长期的系统演化过程中，一部分的架构变化不会对其它部分产生不必要的负面影响。这样做可以确保业务和研发效率的敏捷，让应用的易变部分能够频繁的变化，对应于其它部分的影响尽可能的少。业务架构是生产力，应用架构是生产关系，技术架构是生产工具。业务架构决定应用架构，应用架构需要适配业务架构，并随着业务架构不断进化，同时应用架构依托技术架构最终落地。
  • 好架构是进化来的不是设计来的；我们在每个阶段，找到对应该阶段网站架构所面临的问题，然后在不断解决这些问题的过程中，整个战略的架构就是在不断的演进了。网站在不同的阶段遇到的问题不一样，而解决这些问题使用的技术也不一样，流量小的时候，我们主要目的是提高开发效率，在早期要引入 ORM，DAO 这些技术。随着流量变大，使用动静分离、读写分离、主从同步、垂直拆分、CDN、MVC 等方式不断提升网站的稳定性。面对更大的流量时，通过垂直拆分、服务化、反向代理、开发框架（站点/服务）等等，不断提升高可用。
  • 一个优秀的架构不可能一下就设计出来，是需要不断进化的，当然精心的设计也是必不可少的；好的架构需要经过这么几个过程：精心设计 – 进化 – 进化 …… – 被推翻 – 再设计，是这样循环往复的过程。最开始的架构，肯定是从无到有，根据产品的需求和当时业务的需求设计出来的。一个系统的演化，一般会经过这样的阶段：第一个系统肯定是under-engineer的，从无到有被设计出来后，肯定是不完善的；第二个版本，一般是over-engineer的，因为随着之前那个版本的使用，积累了一定量需求后，会发现想要增加很多内容在上面；到第三个版本，应该是最恰当的，减去了一些没必要的设计之后，更合适。但当到了某一个时间点，发现现有的系统架构已经没有办法再维持下去，跟不上需求增长时，就需要推倒再重新设计。

什么样的组织架构更适合微服务

• 传统技术团队
  • 产品管理专家团队、用户体验专家团队、研发专家团队、测试专家团队、DBA专家团队、运维专家团队
• 新型微服务团队
  • 跨职能微服务团队-API-平台团队
    • 微服务整个团队围绕产品做决定，团队内部的人同时负责：架构、设计、开发、评审、测试、发布、运行、支持，形成闭环；团队规模一般十几个人；谁开发谁构建谁运行发布

如何理解阿里巴巴提出的微服务中台战略

• 大中台，小前台：马云在2015年参观完欧洲一家技术公司有此感悟，提出了中台战略
• 互联网公司组织架构
  • Iaas云平台(基础设施及服务)
    • 计算、存储、网络、监控、安全、IDC
  • Pass云平台
    • 大数据、AI；应用监控、持续交付、服务框架、资源调度、后台服务
  • 核心业务层(领域核心服务)
  • 应用层
    • 主站、app；第三方接入渠道
• 技术中台和业务中台是大中台,当中台比较完善,它对上层应用的支撑能力就越强,使前台更加灵活,快速响应市场需求

如何给出一个清晰简洁的微服务分层方式

• 基础服务:别名-核心领域服务公共服务中间服务
• 聚合服务:别名-适配服务边界服务——>webBFF、MobileBFF、publicBFF

微服务总体技术架构体系是怎样设计的

• 接入层：外部+内部
• 网关层：内部网关、H5网关、无线网关、第三方网关、平台开放网关
  • 网关层在微服务有重要地位，它主要做反向路由、限流熔断、安全...
• 业务服务层:聚合层、基础层
• 支撑服务：注册发现、集中配置、容错限流、认证授权、日志集合、监控警告、后台服务
• 平台服务：发布系统、集群资源调度、镜像治理、资源治理、IAM
• 基础设施：计算、网络、存储、NOC监控、安全、IDC
• 纵向能力：微服务开发框架、持续交付流水线、端到端的工具链、工程实践与规范

微服务最经典的三种服务发现机制

• 在一个分布式架构中有很多服务，这些服务中有生成者有消费者，这些消费者如何去发现生成者，这就需要微服务的服务发现
• 传统Load Balancer做服务发现和负载均衡
  • DNS->Consumer->Load Balancer->Service provider
  • 申请DNS域名、配负载均衡器、域名指向后台服务
• 进程内Load模式发现服务
  • service Register->Consumer(Load Balancer)->Service Provider(定期发送心跳)->service Register：性能好，升级成本高
• 主心独立Load模式
  • 和进程内load模式类似，只不过是在每台消费者主机上部署Load Balancer；应用成本较高
• 服务网格：服务网格是用于控制和监控微服务应用程序中的内部服务到服务流量的软件基础结构层。它通常采取与应用程序代码一起部署，作为网络代理的 "数据平面" 和与这些代理交互的 "控制平面" 的形式。在此模型中，服务网格对于开发人员 (服务所有者) 是透明的， 而运维人员 (平台工程师) 则被授予一套新的工具，以确保可靠性、安全性和可见性。

微服务api服务网关原理与开源网关

• 网关就相当于一个门卫，外部不同的业务调用不同的微服务功能时，我们不希望外部看到微服务细节，通过网关使外界看起来是一个统一的服务
• 外部接入设备->负载均衡器->网关层->微服务
  • 网关功能
    • 反向路由：将外部请求转换为内部的对应微服务调用
    • 认证安全：对请求进来的信息进行安全认证
    • 限流熔断：有突发的大流量冲进来时限流熔断避免服务器承受不了而瘫痪
    • 日志监控:对访问进行记录保存起来，可以进行分析监控
• 开源网关zuul
  • zuul网关核心sevlet
  • zuul网关核心组件zuul Runner：Zuul Runner管理内部过滤器
    • Pre Routing filters(前置路由过滤器)：这里可以加自己定制的过滤器，通过Http Request调用
    • Routing Filters(路由过滤器)：调用后台微服务
    • Post Routing Filters(后置路由过滤器)：这里设置error filters，任何环节报错，抛给错误过滤器处理；通过HttpResponse返回，可以做统计监控的功能
  • zuul中的过滤器是动态插拔的，有灵活的过滤器上传加载机制，zuul网关通过Request Context共享信息
    • 开发完过滤器可以上传到过滤器存储数据库中，后台有一个过滤器Poller，定期从数据库pull过滤器上传到过滤器目录当中，网关上的过滤器管理器定期扫目录，有新的过滤器会加载到网关中

跟Netfix学习微服务路由发现体系

• 服务注册中心Eureka:注册中心，进行服务治理，哪些服务可以随便调用，哪些服务通过网关访问
  • zuul核心组件：服务发现
  • 基础服务：服务注册
  • 聚合服务：服务注册、服务发现

集中式配置中心的作用和原理是什么

• 为什么需要引入配置中心
  • 开发人员一般都把配置放在配置文件中，各自有各自的做法，这样格式不标准，不统一，有很多隐患；上线后修改不方便；没有完整的配置系统，谁修改了配置，无法追溯。
• 哪些可以在配置中心进行配置
  • 连接字符串-消息队列连接字符串-缓存连接字符串、动态调整参数-客户端超时设置-限流阈值、业务开关-某服务只对某个地区生效-某共能只在大促时开放
• 配置中心原理
  • 用户通过一个界面修改配置，不同的微服务可以从配置中心更新配置(手动拉或自动推)
• 协程Apollo配置中心

微服务通讯方式RPC vs REST

微服务框架需要考虑哪些治理环节

• 后台服务集成：数据访问服务、缓存服务、消息服务
• 服务注册发现：消费者如何发现服务
• 负载软路由：应对大流量的负载均衡，灰度发布需要软路由能力
• 日志：日志对于后期排错找问题很重要
• Metrics：对服务的调用量、延迟、出错数进行监控
• 调用链埋点：调用链监控帮助开发人员快速定位问题
• 限流熔断：避免某个服务出现故障或延迟时整个系统的瘫痪
• 安全访问控制：有些服务涉及敏感信息的需要有安全策略，黑名单、访问控制策略来限制对这些服务的访问
• REST/PRC：好的框架同时支持两种通讯方式的调用，不同场景使用不同通讯方式
• 序列化XML/JSON/二进制：灵活配置消息序列化协议
• 代码生成：大规模开发时，推崇契约驱动的开发方法，先定义契约，然后代码生成自动生成服务器端和客户端，生成的代码比较规整
• 统一异常处理：异常处理的统一标准化
• 文档：好的文档体系帮助开发人员更好的利用微服务
• 配置集成：配置中心灵活调整配置

微服务监控系统分层和监控架构

• 端用户体验监控
  • 性能、返回码、城市地区、运营商、版本系统等
• 业务监控
  • 核心指标监控、登录注册、下单、支付等
• 应用监控
  • url、service、sql、cache可用率、响应时间、qps等
• 系统监控
  • 物理机、虚拟机、os：CPU、memory、network、disk等
• 基础设施监控
  • 网络、交换机、网络流量、丢包、错包、连接数等
• 监控哪些方面
  • 日志监控、Metrics监控、健康检查、调用链监控、告警系统

微服务的调用链监控该如何选型

微服务的容错限流是如何工作的

Hystrix的熔断：

• 分布式系统中常见的容错模式：熔断、隔离、限流、降级
• Hystrix内部设计和调用流程：
  • 调用请求：同步调用、异步调用、响应式调用
  • 电路判断：如果电路是打开的(不通了)，直接导入->getFallback(),如果提供了降级函数直接调用->返回，也可能抛出异常，这是短路流程；如果电路是闭合的(通的，没有熔断)->看线程是否ok，队列资源是否满了(是会去降级请求)->运行调用(运行超时，去降级)->调用成功(失败去调用降级)->获取正确的响应->返回到请求方；运行是否成功，调用是否超时都会以message形式反馈给内部计算电路健康的组件，反馈给内部熔断器，从而决定下次电路的开启关闭

Docker容器部署技术&持续交付流水线

• docker容器技术解决的问题和带来的好处
  • 环境一致性：容器技术把依赖包全部打包在容器镜像中，不存在依赖不一致问题
  • 镜像部署：它把构建和发布隔离，提供抽象发布机制；镜像当中有操作系统、依赖包、微服务应用程序
• 交付流水线：Jenkins-镜像治理中心(测试环境-UAT环境-生成环境);在生产环境发布比较严格，可以采用蓝绿发布和灰度发布机制
  • 蓝绿部署原理：我们有蓝色版本和绿色版本，依赖于路由器(网关或内部服务发现系统)；当升级时切换到绿色版本；
  • 灰度发布就是我们不一下子把流量全部切换到绿色版本，而是先切换10%看运行情况，有问题切换回来，没问题再切50%，然后逐步切换

容器集群调度和基于容器的发布体系

• 容器资源调度平台Mesos：他会帮你管理,这个计算机有足够多计算资源和内存资源,看上去是个超级的操作系统,管理下面；master负责管理可以运行容器物理机虚拟机的slave机器，上面有zookeeper来帮助他,有个leader来管理slave,leader出问题,zookeeper会选举一个slave是不同的机器,把自己的使用情况,内存情况等等汇报给master,master把这些信息报告Framework,master只管资源的调度

• 容器发布体系：

  

  微信截图_20191008074041.png

微信图片_20191007223334.jpg