从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
149501 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

36 | 微服务架构最佳实践 - 基础设施篇

每项微服务基础设施都是一个平台、一个系统、一个解决方案,如果要自己实现,其过程和做业务系统类似,都需要经过需求分析、架构设计、开发、测试、部署上线等步骤,专栏里我来简单介绍一下每个基础设施的主要作用,更多详细设计你可以参考 Spring Cloud 的相关资料(https://projects.spring.io/spring-cloud/)。
下面进入今天的内容,微服务架构最佳实践的基础设施篇

自动化测试

微服务将原本大一统的系统拆分为多个独立运行的“微”服务,微服务之间的接口数量大大增加,并且微服务提倡快速交付,版本周期短,版本更新频繁。如果每次更新都靠人工回归整个系统,则工作量大,效率低下,达不到“快速交付”的目的,因此必须通过自动化测试系统来完成绝大部分测试回归的工作。
自动化测试涵盖的范围包括代码级的单元测试、单个系统级的集成测试、系统间的接口测试,理想情况是每类测试都自动化。如果因为团队规模和人力的原因无法全面覆盖,至少要做到接口测试自动化。

自动化部署

相比大一统的系统,微服务需要部署的节点增加了几倍甚至十几倍,微服务部署的频率也会大幅提升(例如,我们的业务系统 70% 的工作日都有部署操作),综合计算下来,微服务部署的次数是大一统系统部署次数的几十倍。这么大量的部署操作,如果继续采用人工手工处理,需要投入大量的人力,且容易出错,因此需要自动化部署的系统来完成部署操作。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(63)

  • 最新
  • 精选
  • 孙振超
    文章中一共列了11个部分,但只有10个人,很明显是不可能是同时开工的,即使能够同时开工也是需要经过几轮迭代才能达到一个比较完善的状态。 依据简单原则和演化原则以及“三个火枪手”的人员分配原则,首先可以做API 网关、配置中心、服务发现、服务路由这4部分,经过一个月的开发+半个月的联调的先让基础框架搭建起来,业务能够运行起来。 业务上线后,为了保证用户体验和问题跟踪,在保留一两个留守同学的情况下,开始服务容错、服务监控、服务跟踪这几部分的开发,因为这个阶段中可能还要回头修改已完成的部分让这几个部分配合的更好,联调的工作量也多了不少,这个过程大概要2.5月。 而后随着业务逐渐增多,流量逐渐增加,为避免被黑产“薅羊毛”需要把服务安全部分给完成,同时为了快速响应新的业务需要把接口框架给完成,但此时有些同学会被已完成部分的日常维护、修bug等,这些初步需要两个月时间。 在这里都完成后,可以开始自动化测试、自动化部署这部分,也按照两个月的时间,这样一轮下来总体需要8个月时间。 经过第一轮后微服务的基础实施是有了,但要真正的运作起来还需要经过几轮的迭代才可以,但此时面对老系统的维护新系统的开发整体的进度会变慢不少,这样一个合格的比较完善的微服务基础设施差不多要两年时间了。

    作者回复: 你是第一个认真分析且抓住重点的同学👍👍

    10
    231
  • Coder4
    看怎么定义自研了,今年花了1个月,每天半小时代码。半开源,半代码,已经实现了 服务发现,追踪,自动部署,以及后端服务数据库,消息队列,缓存,内存数据库的对接, 真正熟悉了,花不了太多时间,另外得合理利用轮子。

    作者回复: 你这个太牛了,惊为天人啊😄

    59
  • 无痕
    老师,很多人把oauth2的鉴权放到了网关,这个你怎么看

    作者回复: 不符合网关的定位,因为有的业务要鉴权有的不要,放在网关就相当于网关要和业务耦合了

    5
    21
  • 程启
    华仔老师, 之前看您留言提到过service mesh不成熟,中小公司不建议使用。请问看起来最近gcp云平台,主推的k8s加上Istio/envoy实现服务治理,您认为未来方向如何,这个是试用中小型团队的方案吗?感谢解答!

    作者回复: 我没有service mesh具体实践经验,主要信息来源于网上资料,意见供参考。 1. Istio刚发布1.0版本,spring cloud成熟很多 2. service mesh中文为服务网格,很形象,说明了更加适合非常多的服务节点,简单来说,如果你只有一两个服务没必要用微服务架构,你只有几十个微服务节点可能也不需要service mesh 3. service mesh对程序无侵入,这点非常好,但随着spring cloud之类的方案成熟,侵入问题其实不是主要问题 因此,我认为大部分中小公司目前不需要service mesh,能把微服务做好已经很不错了。

    18
  • 成功
    30天左右

    作者回复: 太乐观,30天就算用spring全家桶,都不可能上线的

    3
    13
  • 每天学英语的小沈
    微服务这两章讲的非常好,解决了长久以来的困惑

    作者回复: 都是实战经验总结

    9
  • 水云波
    老师,你说API网关的主要包括接入鉴权、权限控制,然后在留言中又说不应该把oauth2的鉴权放到网关。我觉得前后矛盾了,是我对鉴权和权限控制哪里理解的还不到位吗?

    作者回复: oauth2是第三方授权,API网关是二方授权,二方是公司内不同业务部门的请求方和调用方,第三方授权是外部系统,内部系统,用户这三方

    2
    5
  • Geek_steven_wang
    华哥,你好!请问:服务间的安全策略通过配置中心下发给各节点,一般采用那些安全策略?我了解到的有黑白名单(根据服务名、IP),这个方案比较容易伪造(服务名和IP),还有其它策略吗?

    作者回复: 内部网络需要与外部隔离,因此内部反而一般黑白名单用的少,因为机器会经常变,黑白名单管理比较麻烦;通常是给每个服务分配服务名称+服务访问密码之类的做法

    4
  • 空档滑行
    工作量需要看这一套框架要应对的服务规模和流量。以100个微服务,接口平均qps100以下做了简单测算,不考虑同城和异地多活,达到基本可用的话 配置中心,包括配置项管理和推送,和微服务一起打包的客户端 接口框架,使用http和Json的话,只需要一种语言的解析包 Api网关,后端服务对接和接入层实现 服务发现,使用自理式,注册中心服务端加客户端,加注册中心高可用 服务路由,相对简单 服务容错,包括熔断和流控等 服务监控,包括采集和分析 跟踪,各端trace注入,数据上传,数据查询和计算 安全,权限控制,配置支持 按10个高级开发,3人一组的话,大概半年左右

    作者回复: 半年只能出最简单的版本,不完善

    4
  • 依乐祝
    看了这么久第一次留言,老师你好,刚看你说网关层不建议做鉴权!但是如果这样的话,那内部微服务之间如何进行通信呢?我的理解是网关做与url有关的权限处理!而具体的业务服务里面做与数据相关的权限鉴别!这样职业分开!然后内部进行通信的话就可以采用rpc进行高效的交互,而且都是可信的!不知道我的理解是否有误,还请老师指正下哈

    作者回复: 这样是可以的,网关鉴权仅限于和用户相关的登录态,登录环境等,业务权限还是要业务做

    3
收起评论
显示
设置
留言
63
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部