从0开始学架构
李运华
资深技术专家
立即订阅
38972 人已学习
课程目录
已完结 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开始学架构
登录|注册

35 | 微服务架构最佳实践 - 方法篇

李运华 2018-07-17
专栏上一期,我谈了实施微服务需要避免踩的陷阱,简单提炼为:
微服务拆分过细,过分强调“small”。
微服务基础设施不健全,忽略了“automated”。
微服务并不轻量级,规模大了后,“lightweight”不再适应。
针对这些问题,今天我们看看微服务最佳实践应该如何去做。我会分两期介绍这部分内容,今天是微服务架构最佳实践的方法篇,下一期是基础设施篇。

服务粒度

针对微服务拆分过细导致的问题,我建议基于团队规模进行拆分,类似贝索斯在定义团队规模时提出的“两个披萨”理论(每个团队的人数不能多到两张披萨都不够吃的地步),分享一个我认为微服务拆分粒度的“三个火枪手”原则,即一个微服务三个人负责开发。当我们在实施微服务架构时,根据团队规模来划分微服务数量,如果业务规继续发展,团队规模扩大,我们再将已有的微服务进行拆分。例如,团队最初有 6 个人,那么可以划分为 2 个微服务,随着业务的发展,业务功能越来越多,逻辑越来越复杂,团队扩展到 12 个人,那么我们可以将已有的 2 个微服务进行拆分,变成 4 个微服务。
为什么是 3 个人,不是 4 个,也不是 2 个呢?
首先,从系统规模来讲,3 个人负责开发一个系统,系统的复杂度刚好达到每个人都能全面理解整个系统,又能够进行分工的粒度;如果是 2 个人开发一个系统,系统的复杂度不够,开发人员可能觉得无法体现自己的技术实力;如果是 4 个甚至更多人开发一个系统,系统复杂度又会无法让开发人员对系统的细节都了解很深。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(40)

  • 云学
    这篇很实用,谢谢分享

    作者回复: 仅此一家,别无分店,都是我自己思考出来的😄

    2018-07-17
    46
  • herist
    感谢老师对微服务解读,有3个问题:目前公司有个在线交易系统,大概几百个表的单体服务项目,其他业务前端都远程调用这个项目,现在想做微服务的改造。

    1、实施微服务按业务职责划分后,是否对应模块的数据库也必须要独立?

    2、若为每个微服务项目都拆出来新的数据库,原来各业务间的数据依赖(单库的时候Join查询就ok了),拆分多个项目后,有何好的处理办法?

    3、团队开发时的问题,由于每小团队负责一个微服务,但开发时需要访问其他微服务,应该有个开发环境负责集成大家提交的代码,构建新版本供其他团队调用和调试,即:开发团队都可以作为消费者访问服务器上微服务(互通),但是开发人员本机启动调试时,不能注册到这台服务器(隔离),这块如何能很好解决?

    作者回复: 1. 需要,微服务需要独立部署独立运行,数据库不拆分做不到这点
    2. 参考专栏前面分库分表内容
    3. 开发环境也可以搭建微服务,我们是三套环境:开发,测试,线上

    2018-07-18
    1
    9
  • lzh
    三个火枪手分前后端吗?

    作者回复: 一般指后端人员,前端人员是多服务公用的,如果用node之类的系统,本身可以算一个独立的微服务

    2018-07-18
    6
  • Ivan
    使用dubbo体系,开发微服务。那么一个微服务是指一个部署单元(jar or war)还是指一个暴露的接口?我的答案是部署单元。请老师帮忙解惑,谢谢!

    作者回复: 一个可以独立部署和运行的子系统

    2018-07-17
    5
  • 王刚
    听了老师的课对我自己有很大帮助,最近我们公司也在研究微服务~总感觉是一头雾水~希望老师多讲解一下关于微服务经常会涉及到的精髓!

    作者回复: 本篇就是精髓😄😄

    2018-07-18
    4
  • Geek_89bbab
    那么对于像kafka,rabbitmq这样的对应的消费者服务的消费地址是否应该放置到配置中心动态配置?还是不建议动态修改?

    作者回复: 任何配置都可以放配置中心,区别只是动态配置还是需要重启,中间件也不例外

    2018-10-24
    3
  • 小思绪
    请问“接口框架”是指什么?有无成熟产品可以借鉴,它的作用是什么?API网关是指通用网关,比如支付宝开放平台网关,还是业务网关呢?我理解的业务网关的职责应该包括协议转换(比如外网的HTTP转内部Dubbo)和业务逻辑。

    作者回复: 下一课就讲了

    2018-10-05
    3
  • 森林
    这里有个先有鸡还是现有蛋的问题。究竟是先根据人数量决定服务数量,还是根据服务数量决定人的数量。就像文章里提到的,很多时候需要根据各种需求场景拆分服务,当生产确切不拆分就会导致问题时,应该反向以服务数量评估要扩招的人

    作者回复: 招人的第一标准是业务有没有发展😄

    2018-09-20
    3
  • TT
    我觉着我们现在的微服务架构刚好,我们是四个人负责集成公司的规则引擎,引擎那边有规则的编译器和执行器,对应的服务就划分为 规则编辑 和规则执行这两个部分,基本是两人负责一个服务
    2018-08-17
    3
  • 赵武艺
    看来小企业还是不太适合微服务架构,尤其是开发人员少的?

    作者回复: 是的,等业务发展,人员规模大了再重构,90%以上的新业务还没发展就挂掉了😂😂

    2018-07-17
    3
  • 杨陆伟
    为什么说配置中心可以提升测试和运维的效率,这里不是太理解

    作者回复: 不用去几十台服务器几百个节点手工修改配置文件

    2019-03-28
    2
  • Geek_89bbab
    老师,问一下关于配置中心的问题,
    配置中心修改配置,然后通知对应的微服务,那么收到通知的微服务怎么使新的配置生效,我这里特别指的是那些通过配置有创建长生命周期对象的那种。比如mysql连接池,redis-client。比如数据库配置修改了,怎么使新的配置生效?求解惑

    作者回复: 通常这类配置需要重启生效,一般改动频率也低,改动的时候由运维人工参与是可以的

    2018-10-24
    2
  • 孙振超
    咨询老师一个问题:在服务切分的时候会存两个系统间数据发生交集的情况,比如一个是设备系统,另一个是用户系统,用户的各项操作必然发生在设备上,这样就会存在设备和用户的各种关系和操作记录,像这样的数据设备系统和用户系统都希望以自己为准,而后对外提供相应的服务。如果是数据存储两份,设备系统存储设备和用户的关系,用户系统存储用户和设备的关系,那么在数据一致性和调用链路上就会变得复杂;如果只存储一份,放在那个系统上另一个系统都会有意见。对于此种情况,有什么比较好的解法?

    作者回复: 其实你这句话已经包含了答案“用户操作必然发生在设备上”,这就是说设备是基础数据,用户和设备对应关系应该是用户系统管理的。

    还有一种判断标准是设备数据还可以给其它业务用,如果设备系统存储用户和设备对应关系,这个数据不是通用的,违背了设备系统的职责

    2018-09-15
    2
  • 失眠,来听听课吧。微服务的粒度拆分简直堪称一门艺术了。不过七夕啦,单身狗祝大家好好珍惜身边人,也给你的他/她提供微服务化~
    2018-08-17
    2
  • return
    三个火枪手, 很犀利。

    作者回复: 很形象,向大仲马和贝索斯借用了一些创意

    2018-07-21
    2
  • 张威
    我们项目正好相反,将系统拆分了多个子系统,但是同一个库,子系统之间没有相互调用,而是直接对相同库中的表进行操作。在开发过程中发现每个系统中多少会有些重复的代码。该系统是校级系统,目前没发现其它弊端

    作者回复: 正常来说这样有很大隐患,我们之前有后台管理系统这样做,每周都需要安排人力排查线上数据错乱问题,因为数据写入有两个源

    2018-07-19
    2
  • wind2017
    老师,目前Spring Cloud哪个版本更稳定些?

    作者回复: 通常用GA版本就可以

    2018-07-17
    2
  • 星星童鞋
    请问老师,到底项目进展到什么程度,才需要做微服务架构的拆分,可不可以在业务最初设计时就做简单的微服务拆分设计?(在满足人员需求时)

    作者回复: 可以的,一般最开始拆分几个粗一点的

    2019-03-13
    1
  • 随心而至
    Spring cloud全家桶了解一下
    2018-11-01
    1
  • 小思绪
    请问api网关的职责是什么?只负责协议转码参数校验,不包含业务逻辑吗?另外,有没有线下沟通的微信群呢?

    作者回复: 不包含业务逻辑,只负责编解码,路由,安全这些功能。
    暂时没有线下微信交流群

    2018-09-30
    1
收起评论
40
返回
顶部