从0开始学架构
李运华
资深技术专家
立即订阅
38906 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

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

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

自动化测试

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

自动化部署

相比大一统的系统,微服务需要部署的节点增加了几倍甚至十几倍,微服务部署的频率也会大幅提升(例如,我们的业务系统 70% 的工作日都有部署操作),综合计算下来,微服务部署的次数是大一统系统部署次数的几十倍。这么大量的部署操作,如果继续采用人工手工处理,需要投入大量的人力,且容易出错,因此需要自动化部署的系统来完成部署操作。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(38)

  • 孙振超
    文章中一共列了11个部分,但只有10个人,很明显是不可能是同时开工的,即使能够同时开工也是需要经过几轮迭代才能达到一个比较完善的状态。

    依据简单原则和演化原则以及“三个火枪手”的人员分配原则,首先可以做API 网关、配置中心、服务发现、服务路由这4部分,经过一个月的开发+半个月的联调的先让基础框架搭建起来,业务能够运行起来。
    业务上线后,为了保证用户体验和问题跟踪,在保留一两个留守同学的情况下,开始服务容错、服务监控、服务跟踪这几部分的开发,因为这个阶段中可能还要回头修改已完成的部分让这几个部分配合的更好,联调的工作量也多了不少,这个过程大概要2.5月。
    而后随着业务逐渐增多,流量逐渐增加,为避免被黑产“薅羊毛”需要把服务安全部分给完成,同时为了快速响应新的业务需要把接口框架给完成,但此时有些同学会被已完成部分的日常维护、修bug等,这些初步需要两个月时间。
    在这里都完成后,可以开始自动化测试、自动化部署这部分,也按照两个月的时间,这样一轮下来总体需要8个月时间。

    经过第一轮后微服务的基础实施是有了,但要真正的运作起来还需要经过几轮的迭代才可以,但此时面对老系统的维护新系统的开发整体的进度会变慢不少,这样一个合格的比较完善的微服务基础设施差不多要两年时间了。

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

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

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

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

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

    2018-07-20
    5
  • 成功
    30天左右

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

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

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

    2018-07-19
    3
  • 小智e
    老师讲到很好,不过由于自己还是在校生,没经历过,只能得到感性的认识,谢谢老师
    2019-04-11
    2
  • 易燃易爆炸
    自己写的话肯定坑太多,也没有经过太多实践上的检验。感觉真正稳定下来需要躺过很多坑才行,当然成长也是成倍的,最终苦了公司,系统天天挂。
    2018-11-29
    2
  • 程启
    华仔老师,

    之前看您留言提到过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,能把微服务做好已经很不错了。

    2018-08-12
    2
  • mayer
    这10个人分别有相关经验的话,不考虑复杂的业务逻辑实现调试,整个框架搭起来可应用,应该在3个月左右可以完成,条件是高级工程师真的高级,哈哈😄

    作者回复: 太乐观了😄

    2018-07-19
    2
  • Kyle
    Dubbo弄了这么久,配套的基础设施都还没有。高级的水平也有高有低。总觉得怎么也要个一年半载吧。

    作者回复: 一年可以,半载不行😄

    2018-07-19
    2
  • kyll
    按照我们公司的情况来说,1.5个人,spring全家桶,花费6个月,才让系统上线。
    要是完全自研,10个高程在,也信心不大。
    2018-07-19
    2
  • 每天学英语的小沈
    微服务这两章讲的非常好,解决了长久以来的困惑

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

    2019-01-09
    1
  • 文竹
    自动化测试:主要支持接口测试,可以使用robot framework,无需额外人天。

    自动化部署:使用开源jenkins进行构建,无需人天。

    配置中心:需要支持的功能有服务节点管理,节点配置管理,配置版本管理,配置变更通知。
    实现这些功能估计需要30人天。

    接口框架:采用HTTP Rest Json形式,需要指定规范的json格式,目前Json解析能很好地支持于各语言,所以无需提供客户端库。由于主要工作在于规范化,估计需7人天。

    API网关:可以使用开源的API网关,比如Kong。Kong也支持插件化扩展功能。这里估计需7人天。

    服务发现、路由、容错:要实现这三个功能,还要实现服务注册中心。估计60人天。

    服务监控:收集信息并分析,由于数据量比较多,估计需要30人天。

    服务跟踪:是服务监控的升级版,特点也是数据量大,估计需要30人天。

    服务安全:这里需要做一个通用的认证授权方案。估计需要30人天。

    综合以上,似乎一个人半年左右就能完成初版。10个人同时进行的话,估计一个月左右。总觉得估计的时间比较紧,如果根据更细腻度的功能划分的话,可能在2个月左右。

    作者回复: 你还是太乐观了😂

    2018-08-25
    1
  • 凡凡
    按照以往了解的基础架构部的开发速度来看,而且文中涉及的基础设施都有开源实现可以借鉴,一个基础设施从调研(开源系统代码review),到设计,再到开发,再到小流量接入,全公司推广,一个基础设施3个人大概5到6个月时间,如果去掉小流量和推广阶段,估计也需要3到4个月。

    文中说到的前10个微服务,按照单个3*3人月算下来的话,理想情况下,需要9个月。

    当然,这里没有考虑严格的测试和压力测试,否则每个系统,需要增加至少一个人月的周期。

    作者回复: 这类微服务做出基本功能9个月可以,做完善需要耗时更长

    2018-07-19
    1
  • 古月三石
    老师你好,kubernetes中也有服务发现的功能,和Springcloud的服务发现两者如何选择?请指教
    2019-12-06
  • Sam.张朝
    按照第一个人的回答,10个高级工程师,要8个月时间。
    如果没有经验,没有高级,感觉基本就没戏了。

    作者回复: 8个月还算厉害的了

    2019-09-29
  • godtrue
    看完后估不出具体工时,因为具体多复杂不太清楚,而且自顶倒下的工时估算方式是不准确的。如果可能我会把活先分出去,然后让他们给个排期,再看看具体情况给出一个总工期。
    不过,这个东西不好做到是真的,否则大家都自研了,目前应该只有某些大厂才有人力、财力、物力来弄。十个人左右估计需要一年多的时间,如果比较完善的弄出来估计需要三年左右,需要经历大促或者其他流量高峰的考验。还有不断的完善功能,提高效率,提升用户体验。
    2019-09-02
  • 水云波
    老师,你说API网关的主要包括接入鉴权、权限控制,然后在留言中又说不应该把oauth2的鉴权放到网关。我觉得前后矛盾了,是我对鉴权和权限控制哪里理解的还不到位吗?

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

    2019-06-11
  • 郑佳宁
    基础设施为啥要自研呢?有没有现成的成熟框架?如果有,不知道后面作者会不会有对比分析?

    作者回复: 小厂用spring全家桶,大厂为了可控和按需定制,一般会自己做

    2019-06-02
  • zcode
    关于绕过网关进行接口调用的问题,如果通过SDK的方式提供给业务方使用,那是不是业务方也需要登录鉴权了,和网关功能重复了呢

    作者回复: 都封装在SDK里面

    2019-05-31
收起评论
38
返回
顶部