从0开始学微服务
胡忠想
微博技术专家
立即订阅
16289 人已学习
课程目录
已完结 42 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 微服务,从放弃到入门
免费
模块一 入门微服务 (10讲)
01 | 到底什么是微服务?
02 | 从单体应用走向服务化
03 | 初探微服务架构
04 | 如何发布和引用服务?
05 | 如何注册和发现服务?
06 | 如何实现RPC远程服务调用?
07 | 如何监控微服务调用?
08 | 如何追踪微服务调用?
09 | 微服务治理的手段有哪些?
10 | Dubbo框架里的微服务组件
模块二 落地微服务 (14讲)
11 | 服务发布和引用的实践
12 | 如何将注册中心落地?
13 | 开源服务注册中心如何选型?
14 | 开源RPC框架如何选型?
15 | 如何搭建一个可靠的监控系统?
16 | 如何搭建一套适合你的服务追踪系统?
17 | 如何识别服务节点是否存活?
18 | 如何使用负载均衡算法?
19 | 如何使用服务路由?
20 | 服务端出现故障时该如何应对?
21 | 服务调用失败时有哪些处理手段?
22 | 如何管理服务配置?
23 | 如何搭建微服务治理平台?
24 | 微服务架构该如何落地?
模块三 进阶微服务 (8讲)
25 | 微服务为什么要容器化?
26 | 微服务容器化运维:镜像仓库和资源调度
27 | 微服务容器化运维:容器调度和服务编排
28 | 微服务容器化运维:微博容器运维平台DCP
29 | 微服务如何实现DevOps?
30 | 如何做好微服务容量规划?
31 | 微服务多机房部署实践
32 | 微服务混合云部署实践
模块四 展望微服务 (4讲)
33 | 下一代微服务架构Service Mesh
34 | Istio:Service Mesh的代表产品
35 | 微博Service Mesh实践之路(上)
36 | 微博Service Mesh实践之路(下)
阿忠伯的特别放送 (4讲)
阿忠伯的特别放送 | 答疑解惑01
阿忠伯的特别放送 | 答疑解惑02
微博技术解密(上) | 微博信息流是如何实现的?
微博技术解密(下)| 微博存储的那些事儿
结束语 (1讲)
结束语 | 微服务,从入门到精通
从0开始学微服务
登录|注册

24 | 微服务架构该如何落地?

胡忠想 2018-10-16
专栏前面的文章我给你讲解了微服务架构的各个组成部分,以及实践过程中可能遇到的问题和对应的解决方案,到这里你应该对微服务架构有了一个完整的认识。那么在实际项目中,如何让一个团队把我们所学的微服务架构落地呢?
今天我就结合自己的经验,定位在中小规模团队,谈谈微服务架构到底该如何落地

组建合适的技术团队

经过我前面的讲解,你应该认识到微服务架构相比于单体应用来说复杂度提升了很多,这其中涉及很多组件,比如注册中心、配置中心、RPC 框架、监控系统、追踪系统、服务治理等,每个组件都需要专门的人甚至专家把控才能 hold 住,不然微服务架构的落地就相当于空中楼阁,虚无缥缈。
所以想要落地微服务,首先需要合适的人,也就是组建一支合适的技术团队。你一定很容易想到,是不是只有架构师适合做微服务架构的开发?一定程度上,这是合理的,因为微服务架构所涉及的具体技术,比如 CAP 理论、底层网络可靠性保证、Netty 高并发框架等,都对技术的深度要求比较高,一般有经验的架构师才能掌握,所以这个技术团队必须包含技术能力很强的架构师。但是还要考虑到微服务架构最后还是要落地到业务当中,既要满足业务的需求,也要防止一种情况的发生,那就是全部由架构人员组成技术团队,根据自己的设想,脱离了实际的业务场景,最后开发出来的架构中看不中用,业务无法实际落地,既打击了团队人员积极性,又对业务没有实际价值,劳民伤财。所以这支技术团队,也必须包含做业务懂业务的开发人员,只有他们了解业务的实际痛点以及落地过程中的难点,这样才能保证最后设计出的微服务架构是贴合业务实际的,并且最后是能够实际落地的。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学微服务》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(24)

  • Dhy
    微博今天瘫的了
    2018-10-16
    1
    31
  • yixiao
    老胡啊,微博又宕机了?哈哈哈
    2018-10-16
    17
  • 冬末未末
    可以分享一下这次微博挂了之后你们的恢复流程么
    2018-10-16
    13
  • 13
    微博今天又炸了啊
    2018-10-16
    11
  • echo_陈
    小型团队可能一开始就不愿意自研,甚至没有架构师,都是直接找一个开源框架,如dubbo,然后参考Demo迅速进入业务开发。自然而然的就形成了微服务的雏形,已经上线的了后台,可能一开始基础设施严重缺失,可能也没有监控,经常发生了问题就是黑盒子,往往是事后慢慢完善基础设施,但也是很漫长的和阵痛的过程
    2018-10-16
    6
  • 西夏一品堂
    微服务如何应对突发的流量(明星公布恋情)
    2018-10-17
    5
  • 苹果xixi
    微博在做注册中心选型的时候,没有选取当时很火的 Zookeeper 的一个重要原因就是,它底层依赖的是 HBase 存储??这句话不理解,zk和hbase怎么关联到一块了?

    作者回复: 这一块写反了,hbase依赖zk,没有选取zk的主要原因是对zk的掌握不够,没有这方面的专家

    2018-11-01
    4
  • 飞呀飞
    测试环境需要和线上环境保持一致,这个时候需要docker。某一个业务进行测试的时候,就将它所依赖服务,更新到沙箱主机。
    另外也需要进行单元测试,单元测试case尽可能的覆盖广泛。

    没有实践过,希望可以得到忠伯的指导。
    2018-10-16
    3
  • Saily
    说好的8个明星并发出轨呢,单个明星结婚都挂了😂😂
    2018-10-17
    2
  • 又宕机了 怎么落地微服务的啊
    2018-10-16
    2
  • godtrue
    怎么测试?
    这个就费劲了,假如一个项目涉及三个小组A/B/C
    1:拉个群包括三个小组的相关开发、测试、产品,以及项目经理等人员
    2:约定测试环境、测试用例、准备好测试数据
    3:开测,测试的过程中出现问题在群里沟通,在群里解决,有逼在群里撕
    4:如果顺利还挺快,否则就要拉相关小组负责人一起撕,还撕不好,就开会
    5:沟通很重要,尤其是涉及的人员众多的时候,各自站在自己的立场上有些锅会飘来飘去的,经过几轮螺旋上升最终项目还是能上线的
    2019-06-15
    1
  • andyXH
    首先保证有一个完整的调用链的测试环境,然后使用这个环境注册中心,部署微服务,从而获取这个环境所有依赖服务。
    2018-10-25
    1
  • 爪哇夜未眠
    老师好,请问微服务系统下数据库被拆分成多个库,那做一些联表查询的时候怎么操作呢?
    2018-10-19
    1
  • 幻想
    好文,说到心坎上了。目前我是负责公司核心业务系统的从0到1的微服务重构。不过文中提到的,先以一个业务应用发布成微服务,并且把微服务配套的监控、运维手法等等都搞定后,才开始考虑垂直拆分其他业务应用的说法,应该是站在公司系统流量比较大的情况。像一些创业公司的应用,流量还不大,但又是单体应用,且开发人员越来越多,开发效率很低,越来越不能满足产品经理越来越多的需求,迭代效率很低。这个时候,多垂直拆分几个应用,发布成微服务,我觉得没问题。
    2018-10-16
    1
  • 波波安
    每个业务的服务都将自己的服务发布到指定的注册中心,同时保证稳定性。这样做服务测试的时候,所有的依赖都订阅这个稳定的注册中心的服务来测试。
    2018-11-15
  • 章鱼哥
    怎么做测试ne
    2018-10-24
  • Li Shunduo
    思考题有没有参考回答?
    2018-10-23
  • arebya
    zookeeper底层依赖hbase做存储?
    2018-10-20
  • 旭东
    一个明星比好几个春晚都厉害😄
    2018-10-19
  • 文敦复
    如果需要第三方的服务来进行支撑的话,最好通过Interceptor的形式在本地就返回,这样不依赖第三方进行测试。
    2018-10-18
收起评论
24
返回
顶部