Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
晶之木
advanced-java
提交
71876703
A
advanced-java
项目概览
晶之木
/
advanced-java
与 Fork 源项目一致
从无法访问的项目Fork
通知
3
Star
1
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
A
advanced-java
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
前往新版Gitcode,体验更适合开发者的 AI 搜索 >>
提交
71876703
编写于
3月 21, 2019
作者:
Y
yanglbme
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
docs(distributed-system): update docs description of dubbo
上级
c0cc3ca1
变更
3
隐藏空白更改
内联
并排
Showing
3 changed file
with
5 addition
and
5 deletion
+5
-5
docs/distributed-system/dubbo-operating-principle.md
docs/distributed-system/dubbo-operating-principle.md
+1
-1
docs/distributed-system/dubbo-service-management.md
docs/distributed-system/dubbo-service-management.md
+1
-1
docs/distributed-system/why-dubbo.md
docs/distributed-system/why-dubbo.md
+3
-3
未找到文件。
docs/distributed-system/dubbo-operating-principle.md
浏览文件 @
71876703
...
...
@@ -32,4 +32,4 @@ MQ、ES、Redis、Dubbo,上来先问你一些思考的问题,原理(kafka
![
dubbo-operating-principle
](
/images/dubbo-operating-principle.png
)
### 注册中心挂了可以继续通信吗?
可以,因为刚开始初始化的时候,消费者会将提供者的地址等信息
**拉取到本地缓存**
,所以注册中心挂了可以继续通信。
可以,因为刚开始初始化的时候,消费者会将提供者的地址等信息
**拉取到本地缓存**
,所以注册中心挂了可以继续通信。
\ No newline at end of file
docs/distributed-system/dubbo-service-management.md
浏览文件 @
71876703
...
...
@@ -34,7 +34,7 @@
-
每个服务的可用性的监控(接口调用成功率?几个9?99.99%,99.9%,99%。)
### 服务降级
比如说服务 A调用服务 B,结果服务 B 挂掉了,服务 A 重试几次调用服务 B,还是不行,那么直接降级,走一个备用的逻辑,给用户返回响应。
比如说服务 A
调用服务 B,结果服务 B 挂掉了,服务 A 重试几次调用服务 B,还是不行,那么直接降级,走一个备用的逻辑,给用户返回响应。
举个栗子,我们有接口
`HelloService`
。
`HelloServiceImpl`
有该接口的具体实现。
...
...
docs/distributed-system/why-dubbo.md
浏览文件 @
71876703
...
...
@@ -8,7 +8,7 @@
早些年,印象中在 2010 年初的时候,整个 IT 行业,很少有人谈分布式,更不用说微服务,虽然很多 BAT 等大型公司,因为系统的复杂性,很早就是分布式架构,大量的服务,只不过微服务大多基于自己搞的一套框架来实现而已。
但是确实,那个年代,大家很重视 ssh2,很多中小型公司几乎大部分都是玩儿 struts2、spring、hibernate,稍晚一些,才进入了spring mvc、spring、mybatis 的组合。那个时候整个行业的技术水平就是那样,当年 oracle 很火,oracle 管理员很吃香,oracle 性能优化啥的都是 IT 男的大杀招啊。连大数据都没人提,当年 OCP、OCM 等认证培训机构,火的不行。
但是确实,那个年代,大家很重视 ssh2,很多中小型公司几乎大部分都是玩儿 struts2、spring、hibernate,稍晚一些,才进入了
spring mvc、spring、mybatis 的组合。那个时候整个行业的技术水平就是那样,当年 oracle 很火,oracle 管理员很吃香,oracle 性能优化啥的都是 IT 男的大杀招啊。连大数据都没人提,当年 OCP、OCM 等认证培训机构,火的不行。
但是确实随着时代的发展,慢慢的,很多公司开始接受分布式系统架构了,这里面尤为对行业有至关重要影响的,是阿里的 dubbo,
**某种程度上而言,阿里在这里推动了行业技术的前进**
。
...
...
@@ -24,7 +24,7 @@
假设一个系统是 20 万行代码,其中 小A 在里面改了 1000 行代码,但是此时发布的时候是这个 20 万行代码的大系统一块儿发布。就意味着 20 万上代码在线上就可能出现各种变化,20 个人,每个人都要紧张地等在电脑面前,上线之后,检查日志,看自己负责的那一块儿有没有什么问题。
小A 就检查了自己负责的 1 万行代码对应的功能,确保
ok
就闪人了;结果不巧的是,小A 上线的时候不小心修改了线上机器的某个配置,导致另外 小B 和 小C 负责的 2 万行代码对应的一些功能,出错了。
小A 就检查了自己负责的 1 万行代码对应的功能,确保
ok
就闪人了;结果不巧的是,小A 上线的时候不小心修改了线上机器的某个配置,导致另外 小B 和 小C 负责的 2 万行代码对应的一些功能,出错了。
几十个人负责维护一个几十万行代码的单块应用,每次上线,准备几个礼拜,上线 -> 部署 -> 检查自己负责的功能。
...
...
@@ -44,7 +44,7 @@
如果是多人维护一个服务,最理想的情况下,几十个人,1 个人负责 1 个或 2~3 个服务;某个服务工作量变大了,代码量越来越多,某个同学,负责一个服务,代码量变成了 10 万行了,他自己不堪重负,他现在一个人拆开,5 个服务,1 个人顶着,负责 5 个人,接着招人,2 个人,给那个同学带着,3 个人负责 5 个服务,其中 2 个人每个人负责 2 个服务,1 个人负责 1 个服务。
个人建议,一个服务的代码不要太多,1万行左右,两三万撑死了吧。
个人建议,一个服务的代码不要太多,1
万行左右,两三万撑死了吧。
大部分的系统,是要进行
**多轮拆分**
的,第一次拆分,可能就是将以前的多个模块该拆分开来了,比如说将电商系统拆分成订单系统、商品系统、采购系统、仓储系统、用户系统,等等吧。
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录