从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开始学微服务
登录|注册
29 | 微服务如何实现DevOps？
胡忠想 2018-10-27
把一个大的单体应用拆分成多个微服务之后，每个服务都可以独立进行开发、测试和运维。但当拆分的微服务足够多时，却又仿佛陷入一个新的泥沼，无论是业务代码的开发还是测试和运维，工作量都比之前提升了很多。
采单体应用架构时，一个业务需求只需要修改单体应用的代码，然后针对这个单体应用进行测试，测试通过后再把单体应用的代码发布到线上即可。而拆分为微服务之后，一个大的系统被拆分为多个小的系统，一个业务需求可能要同时修改多个微服务的代码，这样的话多个微服务都需要进行测试，测试通过了都需要把代码发布到线上，显然工作量成倍增加。这时候就迫切需要一种新的开发、测试和运维模式来解决这个问题，这就是今天我要给你讲的微服务与 DevOps。
什么是 DevOps？
在介绍 DevOps 之前，我先来带你回顾一下传统的业务上线流程：开发人员开发完业务代码后，把自测通过的代码打包交给测试人员，然后测试人员把代码部署在测试环境中进行测试，如果测试不通过，就反馈 bug 给开发人员进行修复；如果通过，开发就把测试通过的代码交给运维人员打包，然后运维人员再发布到线上环境中去。可见在传统的开发模式下，开发人员、测试人员和运维人员的职责划分十分明确，他们往往分属于不同的职能部门，一次业务上线流程需要三者之间进行多次沟通，整个周期基本上是以天为单位。你肯定会想假如能够把开发、测试和发布流程串联起来，就像生产流水线上那样，每个步骤完成后，就自动执行下一个步骤，无须过多的人为干预，业务的迭代效率不就能提升很多吗。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学微服务》，如需阅读全部文章，
请订阅文章所属专栏。
请订阅文章所属专栏。
立即订阅
登录 后留言
精选留言(9)
拉欧单元测试是对每一个接口，每一个方法进行边界验证，集成测试是对整个调用流程进行测试，一般来说单元测试全通过集成测试也可能会暴露一些问题，但是单元测试不通过集成测试一定gg作者回复: 是的，单测阶段能发现的问题最好不要遗留给集成测试
2018-10-28 7
shawnJekins 应该是 Jenkins。
顺便问一下，拆分成微服务之后，服务之间的兼容性是怎么处理的呢？作者回复: 多谢指正，这里兼容性指的是啥？
2018-10-28 3
AmosWooo我的理解是UT是从函数粒度来保证业务逻辑的正确性合理性，可以帮助发现业务逻辑缺陷; IT则是从接口粒度来保证整个系统在子服务的协同下可以达到预期输出。IT作为软件系统交付的前一环节，主要是进一步验证系统核心业务逻辑的可用性，稳定性。作者回复: 是的
2018-10-27 3
小呀嘛小二郎微服务的模块太多，如何本地实现多服务测试，是再搭建一个开发环境嘛，那注册上去的节点我们可以通过dubbo配置嘛，是我本地注册上去的节点2018-12-19 1
godtrue单元测试：确认方法级别的逻辑正确性
集成测试：确认接口级别的逻辑正确性
目前我们的测试不是这么玩的基本需要人员来触发，不是自动化的，感觉也不容易自动化。
我们的环境也都是隔离的分成开发、测试、预发布、线上等。
测试起来流程也比较多：
1：研发开发及自测
2：测试测试
3：视情况而定，可能需要预发布联调测试
4：合主干回归测试
5：视情况而定，可能需要业务线上验证测试
6：以上比较顺利，则可以线上跑起来啦2019-06-16- suke请问微服务应该如何做到自动化的灰度发布或者金丝雀发布2019-02-27
勤之鹿web1.0时代即单体应用时代的产品有必要做单元测试吗？我们团队的成员都没有编写单元测试的习惯，请问该如何养成这些好的习惯呢？2018-11-09
幻想写的太好了，收货颇多。作者回复: 哈哈，有收获就好
2018-10-28- 有铭集成测试时跑测试用例你们是自动化的吗，用的什么工具实现自动化的测试用例？
作者回复: 我们是自己研发的集成已有的自动化测试用例
2018-10-27
收起评论