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

34 | 深入理解微服务架构:银弹 or 焦油坑?

李运华 2018-07-14
微服务是近几年非常火热的架构设计理念,大部分人认为是 Martin Fowler 提出了微服务概念,但事实上微服务概念的历史要早得多,也不是 Martin Fowler 创造出来的,Martin 只是将微服务进行了系统的阐述(原文链接:https://martinfowler.com/articles/microservices.html)。不过不能否认 Martin 在推动微服务起到的作用,微服务能火,Martin 功不可没。
微服务的定义相信你早已耳熟能详,参考维基百科,我就来简单梳理一下微服务的历史吧(https://en.wikipedia.org/wiki/Microservices#History):
2005 年:Dr. Peter Rodgers 在 Web Services Edge 大会上提出了“Micro-Web-Services”的概念。
2011 年:一个软件架构工作组使用了“microservice”一词来描述一种架构模式。
2012 年:同样是这个架构工作组,正式确定用“microservice”来代表这种架构。
2012 年:ThoughtWorks 的 James Lewis 针对微服务概念在 QCon San Francisco 2012 发表了演讲。
2014 年:James Lewis 和 Martin Fowler 合写了关于微服务的一篇学术性的文章,详细阐述了微服务。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(64)

  • Tom 置顶
    我们公司的实践是比较粗粒度的子系统或服务,基本上没有太细粒度的微服务,以webapi为主。感觉更像微服务架构,只是服务粒度比较粗,从概念上算是SOA还是微服务架构呢?

    作者回复: 我理解算微服务,千万不要理解为微服务就是将服务拆的很细,后面有具体实践技巧介绍这部分

    2018-08-10
    6
  • 鹅米豆发
    对于一个新事物的诞生,本能地套用已有的知识。特别是一个并不简单的东西,这算是一种高效的入门方法。微服务架构其实相当复杂,我是分成好几个阶段理解。

    1、第一阶段,微服务架构就是去掉了ESB的SOA架构,只不过是通信的方式和结构变了。对于初级的使用者而言,这样理解没有太大问题。

    2、第二阶段,没有了ESB,原本很多由ESB组件做的事儿,转到服务的提供者和调用者这里了。他们需要考虑服务的拆分粒。大体仍然算是SOA架构。

    3、第三阶段,随着服务的数量大幅增加,服务的管理越来越困难,此时DevOps出现了。这个阶段的微服务架构,已经是跟SOA架构完全不同的东西了。

    之前给一家大国企分享过一些经验。他们想从传统架构,转向微服务架构。

    1、建设好基础设施,RPC、服务治理、日志、监控、持续集成、持续部署、运维自动化是基本的,其它包括服务编排、分布式追踪等。

    2、要逐步演进和迭代,不要过于激进,更不要拆分过细,拆分的粒度,要与团队的架构相互匹配。(康威定律)

    3、微服务与数据库方面,是个很大的难点,可以深入了解下领域驱动设计,做好领域建模,特别是数据库要随着服务一起拆分。

    说完上面这些,他们的研发负责人说,我说的跟他们的架构师说的不一样,他们的架构师说,微服务就是各种拆分,不顾一切地拆分。

    作者回复: 他们架构师是水货😂你的理解和分析是对的,后一篇就讲了

    2018-07-16
    39
  • 空档滑行
    之前一家公司搞了一次完整的微服务改造,享受到了一些好处,但是文中说到的问题,大部分都碰上了。
    先说下好处,原来的单体应用都服务化了,扩容简单很多。功能隔离后之前一个bug导致系统挂掉的现象没了。问题责任定位划分的更清楚,比如之前大量慢sql无人管,现在通过监控快速找到开发责任人。
    再说下坏处,1.服务太多了,人不够啊。之前的架构师按照小的原则,把数据层,服务层,应用层严格拆分。一个人手上超过10几个服务...
    2.服务化不彻底,太多事手工干。服务监控只能监控一半指标,各种远程调用异常没人解决。运维只有打包发布做了自动化。可以想象下开发人员基本下改bug和发布的死循环中。服务网关没有,服务调用就是一张密密麻麻的网
    3.培训不到位,直接上阵,开发人员对微服务理解不到位,服务质量可想而知
    4.没有专职测试,自动化测试靠开发写脚本,谁有空啊,单元测试能写一个就算相当有觉悟了
    总结下来,做服务化改造首先问自己这些问题,业务真的需要微服务来解决吗?真的所有模块的问题都要微服务来解决吗?技术人员的配置和水平达到要求了吗?
    2018-07-14
    1
    25
  • ant
    我们是一家社交公司,后端加厚的演变符合dubbo官网的那张图,在Mvc架构坚持了一年后,业务越来越大,工程越来越臃肿。后面我们一致同意进行服务话,开始用了dubbo。后面由于决策层的原因没有上,后面来了个架构师,又重启了服务拆分,到现在已经用于生产。我们使用的是Spring cloud,现在拆分暴露了很多问题:
    1、个别服务没有熔断出来,出现过雪崩效应
    2、服务拆分过细,服务调用链过长
    3、开发人员能力不一样,代码水平不一样
    4、没有监控措施
    5、每个服务部署多台,日志查询就会死人的感觉
    6、开发过程中经常出现访问不到该访问的接口,这是因为开发人员经常启动本地服务,就会导致30%的概率访问不到
    7、使用了不合理的持久层框架,使用了JPA访问
    大概就有上面的问题,总之微服务不是银弹,用得不好会发现无穷无尽的坑。当然,出现问题解决问题就是了。唯一的就像CEO说的: 你们他妈的是完全在拿用户当小白鼠使用

    作者回复: 用户会用脚投票的😂😂

    2018-07-16
    10
  • 凡凡
    说到微服务,切分的粒度和基础设施都致关重要。

    经历的项目有创业初期的单体服务,也有不太完善的服务切分的系统,也有微服务基础设施相对完善的公司。

    单体服务致命就致命在随着项目的发展,项目会越来越臃肿,越不利于扩展开发。

    微服务过程怕就怕基础不完善,人员配备不够盲目切分,导致工程师开发和维护的战线拉长,特别疲惫和泄气,容易产生一种抱怨的大气氛,从而导致微服务失败,重新合并一部分服务。

    微服务做的好的,也有所经历,公司的基础设施完全云化和统一管理,申请几台机器,一套缓存集群,一套mq,sql/nosql…特别容易,工程师愿意建独立的工程,因为很容易构建和部署。这种感觉有点像svn和git,git建分支特别轻量,大家都愿意用分支管理自己的代码,迭代开发,应急处理都能自由切换,得心应手。

    现在遇到一个问题,就是微服务内部系统大多使用rpc,但对接外部系统,或者跨外网传输到客户端就需要http-rest类的协议。也就是我们常说的网关,如果是纯http就很容易做到通用的转发机制,但是http转rpc就不知道有什么方式可以做到通用转发了,内部每增加一个rpc,网关就需要增加一个对应的服务处理逻辑。不知道,这个问题,有没有好的解决办法?

    作者回复: 把HTTP转RPC做成规则,别硬编码每个接口,例如,规定HTTP URL为/service/interface/method?para1=xxx&para2=yyy

    2018-07-16
    8
  • 木头旮瘩
    让我想起了一次面试经历,一家小公司,技术团队大概7 8个人,然后他们要进行微服务架构改造,我问他们:你们这样满足康威定理么?他们一脸懵逼……我就果断闪人了

    作者回复: 你可以去改造他们😂

    2018-12-12
    7
  • 三棱镜
    我们目前全部微服务,踩坑踩了不少,拆分服务同时要把自动化运维系统和多维度监控系统,包括问题定位跟踪系统建立起来,要不然拆了就是噩梦。

    作者回复: 感同身受啊😄

    2018-08-17
    1
    6
  • Neal
    1. 数据库拆不开
    2. 人手不够就两人
    2018-07-16
    4
  • 孤独患者
    我们公司的平台就是使用微服务架构,十多二十个微服务,但是没有自动化部署,监控,自动化测试这些,而且每次报错日志也特别难找,但是我们那架构师却不重视这些,只想继续升级平台的功能

    作者回复: 让你们架构师来订阅架构专栏😂😂😂

    2018-07-15
    4
  • Jussi Lee
    我们项目之前是把数据采集,和展示都是我们Java组去写的。后面公司为了统一,把采集部分交给了.net组。我们Java只负责数据展示。但是我们这边又按照领导的要求把整个业务拆分为模板解析层-》api层——》终端层。现在每次最烦的事就是找bug。一直感觉现阶段我们的任务和目标没有这么庞大,这与架构中的简单和合适原则想违背。搞的整个项目组一直在反复的开发工作中。都很心累

    作者回复: 很好的案例👍

    2018-09-18
    3
  • 正是那朵玫瑰
    我们的业务也算是微服务吧, 接手项目时,已经有好多服务,主要采用的语言有java,php,nodejs,存在以下问题:
    1、没有一个统一的网关服务,前端请求后端服务都需要后端的服务A来充当安全校验,权限校验等,A服务充当了多重职责,变的职责不明确了,后来抽出网关系统,负责平台统一的流量入口。在构建微服务网关系统是至关重要的。
    2、监控系统不完善,调用链跟踪,异常报警都不完善,对微服务是巨坑,查找问题如同一场噩梦,调用链很长,一旦发生异常不知道到底哪里出现问题,得一个一个去找。后来慢慢完善,变得好了很多,问题很快定位。
    3、加入网关后,没有一个统一的服务发现注册中心,网关的路由依靠人工手动配置,变的很麻烦,也很容易出错。后来引入consul,得到改善。

    作者回复: spring全家桶,你值得拥有😂

    2018-07-14
    3
  • Daniel大东
    能否来一篇中台战略和微服务的文章?

    作者回复: 我跟编辑聊聊看

    2019-06-10
    2
  • 乘风
    16年时,架构师引入了微服务架构,架构设计分为三层:网关层、业务处理层、数据处理层(getaway->ls>ds),自上而下依赖,业务层之间也互相依赖,构建过程中发现引入了分布式事务和调用链长(调用链的消耗时间无法接受),经常无故报错,定位问题慢,测试复杂等问题,而我们的大多数业务相对简单,所以重新划分服务粒度,分为两层:网关层:提供路由功能,业务处理层:处理请求,业务层中间可以相互调用,当出现有出现分布式事务时,采取MQ或者更新状态的方式解决,如果是充值+业务订单的这种会直接在一个事务里处理(其实这里就混乱一点了),层与层之间没有完全隔离,但是将调用链缩短,我觉得采用微服务架构确实解决了单体应用的一些问题,如资源问题(但消耗资源是比以前多的)、耦合问题、快速迭代问题,服务与服务的职责更加清晰,不同的服务粒度设计的系统是天差地别的。

    作者回复: 是的,粒度太重要了

    2018-12-11
    2
  • 冬阳(Wolfer Chen)
    我个人比较认同康威定律,微服务的拆分粒度一定要和组织结构匹配起来,组织结构和开发管理模式是微服务粒度的最重要参考指标之一。

    作者回复: 是的,康威定律和微服务拆分是相关的

    2018-11-08
    2
  • 森林
    概念是会一直演化的,我相信最初的SOA的概念就是作者所说的形式,但是仅仅从"面向服务的架构"这几个字来说,难道他就不能是微服务的超集么?在微服务名字出来前,用dubbo的系统是怎么称呼其架构的?微服务定义一开始还要求一定是基于Rest的,难道用dubbo的就不是了?所以个人觉得,理解历史可以,但限定于SOA就一定是基于ESB做协议转换联通各个系统的一种架构是不妥的。

    作者回复: 如果从历史产生的背景去理解,那就每个人都有自己的理解,没法沟通交流呢😊

    2018-09-20
    2
  • 各个诗坤
    我记得有一次做业务,当时不知道什么原因,整体使用微服务,当时是个新业务,完全从0开始,没有任何用户基础,当时按照业务把服务拆成了7.8个微服务,但没有自动化,服务还是部署在一台机器上,服务之间也没有服务治理,服务之间的调用链很长,开发就4.5个人,定位问题花费时间长,典型的基础服务也跟不上。现在想想,当时团队不知道咋想的,觉得微服务比较新就上了,完全没有考虑到产生的问题。还好后来这块业务黄了。要不然估计坑更多。对于创业公司来说,刚开始的时候,其实一个服务就够了,真等用户上来了,业务有希望了,那时候再上其他架构模式也不迟,忌讳一开始就求新求全,说到底,对于大部分公司来说。技术是为业务服务的。

    作者回复: 你们缺少一个真正的架构师😂

    2018-08-21
    2
  • 旭东
    个人觉得SOA只是提出了面向服务的编程,到但没有对服务粒度的定义,以及服务的治理问题做深入的分析。
    提出微服务主要是为了解决面向服务架构后如何能够在实际工程中带来真正的红利。
    微服务对SOA的技术关键点给出了指导意见。


    微服务对分布式服务的诱惑力的确很大,但做但微服务都不会免费的,需要很多的基础设施来做铺垫和基石,才有可能搞定。

    除了基础设施还有很多设计思想需要学习,我觉得DDD就是微服务的绝配。

    作者回复: SOA是完整的解决方案哦,IBM等公司卖ESB都卖了好多钱😀

    2018-08-09
    2
  • 衣申人
    同问:dubbo和motan这类rpc框架,是微服务框架??

    作者回复: dubbo可以算微服务基础设施的一部分,主要承担服务注册发现等

    2018-07-15
    2
  • 波波安
    我们用的是dubbo。最开始系统要快速上线,所以服务拆分的不彻底。订单,商品,店铺等这些服务都没有进行拆分。就把支付和营销两个服务拆分出来了。服务拆分不彻底经常导致一个业务有问题。整个系统都用不了。

    作者回复: 不是拆分有问题,是配套基础设施有问题

    2018-07-15
    2
  • narry
    我弄微服务遇到最大的坑,就是jvm与docker兼容性不好,导致每个微服务会消耗过多不必要的内存,我感觉从资源消耗上来说,java开发的微服务都不能算是微服务了,最近在转向go来改造

    作者回复: 这还真是第一次听说jvm与docker不兼容,看看是不是有bug

    2018-07-14
    2
收起评论
64
返回
顶部