总摘要: 解耦. 接口降低. 架构.

2017-11-27

• 摘要: 解耦. 接口降低. 架构.

1.为什么说解耦的战术，决定了架构的高度？[成都-梅小西]

北京-喜<-> 15:16:00
理论上 确定是解耦的能力 等于架构的高度。 但是不是他列举的那些解耦例子, 今天终于刚刚梳理下，总共3个方面.
北京-喜<-> 15:17:15
1：端对端的交互方式 2：端内的应用架构 3：数据架构。 3种都涉及解耦和协作. 端对端的交互方式：本质上是3种。 (通常说的事件驱动、ACTOR、工作流、分层架构、甚至是同步命令，都是这一层的)。 3种本质是啥自己总结吧. 端内的应用架构：比如DDD、ACOTR、内部分层涉及、一些执行框架，都属于这一层.
北京-coder-在线教育(-) 15:20:38
数据架构，就是大数据了呗
北京-喜<-> 15:20:57
简单说：数据视图和计算, 比如CQRS、大数据、多维异构数据等.
广州-小护士<-> 15:22:28
AWS Lambda 服务属于端对端还是数据架构？
北京-Easy哥(-) 15:24:39
这个 覆盖面太广了 甚至是一种 反命令式架构设计方案
广州-小护士<-> 15:25:09
反命令式架构是什么？我就是很疑惑 函数运算到底是哪种。。
北京-Easy哥(-) 15:25:50
我们平时 提的各种设计方案 都是基于命令式这个前提 , 也是现在 计算机设计的基本方式 , 但是 当年 设计计算机的时候 可不只这一个方案 , 还有一种 就是所谓 函数式设计 函数式设计的好处 就是 命令式设计要追求的那些东西 . 近些年 随着 云端应用的兴起 简单的单服务应用 被提上了新高度. 所以 业界又开始搞一些鬼 发现 我擦 函数式设计有好多东西 很符合我的要求啊. 所以 就拿来 鼓捣鼓捣 组合出一个名词 FAAS.然后 有了这个名词 亚马逊作为云世界领军人 自然要出个产品 .曰 Lambda架构
南京-wyy(-) 15:28:54
关键在于计算能力的提高吧，函数式重新流行起来
北京-Easy哥(-) 15:29:52
关键在于 现在的系统 复杂度 到了 不能单纯用命令式设计模式解决的地步了, 所以 要解决复杂度 需要一些特殊思考方式 , 函数式的优势 能够补充 命令式的短板
北京-喜<-> 15:29:54
类似视角的问题，有中心和无中心
杭州-光明消逝(-) 15:31:11
简单看了下faas,这在设计中,就是根据事件写很多的ifelse
北京-Easy哥(-) 15:31:33
这本身就是错的, 都已经是faas了 目的是消除 if else 和 循环. 函数式 更省资源,因为 函数式对内存的需求是最低的.
北京-喜<-> 15:35:40
函数式 和 所见即所得有一定冲突
南京-wyy(-) 15:34:53
@北京-Easy哥 那为啥一直是命令式大行其道呢？
北京-Easy哥(-) 15:35:44
那是因为 冯诺依曼依据命令式设计的计算机 所以 很长一段时间 函数式设计被认为是 邪教.命令式设计 或者说 图灵机 是因为 图灵不但提出了计算方式 而且 给出了工程上的设计 . 图灵他老师 邱奇 把这玩意 弄成了数学的分支, 由此可见 工程素质多么重要, 这是因为 这几十年 大家的学习的路子都是命令式的
北京-喜<-> 15:37:48
复杂度不断上升后，函数式在整体业务上理解成本会上升, 也许是因为函数式没发展起来，对应理论和方法 没普及. 另外一个就是 函数式没有 基础设施
北京-Easy哥(-) 15:40:37
函数式语言的意思是 在命令式设计的机器上跑函数式计算 自然要多消耗转化的成本

2. 接口降级有什么资料吗? [深圳-Mt]

北京-jax(-) 18:04:29
得看你们用的框架，springcloud hystrix
深圳-Mt<-> 18:06:29
我去看看hystrix 的实现吧
广州-小护士<-> 18:08:32
hystrix的实现跟降级本身无关, hystrix 里面只是一个有限状态机, 开，半开，关闭状态, 定时轮询+状态变换，没了. 降级是具体业务上的事情, 我的意思是，做降级不一定非要用 Hystrix 啊.
广州-Ryan(-) 18:14:59
去枝叶保主干呃，接口的边角逻辑直接干掉，主干逻辑保留。
接口自身做好过载保护，强依赖下游做好调用熔断和自动恢复。
就是保证自己不挂，也保证不要搞挂别人。
广州-Galen(-) 18:16:31
这样子接口规范就要做得很明确了吧？上游接口这样做，问题应该不大，下游接口考虑的点也很多。
广州-小护士<-> 18:17:53
接口设计得好不好，跟架构有直接关系~
广州-Ryan(-) 18:20:39
接口规范这个是需要保证的，不过和降级关系不大。
要做成自动化，就得在 逻辑前后加一些东西，比如 A | B | C，B是你的接口，A是进入你接口前，你可以根据一定规则拒绝，达到过载保护。
B就是你的下游，同理。
广州-Galen(-) 18:24:18
其实这么说，上游要搞好过载保护，下游要搞好熔断和恢复。和你上句说的同理，这些可以抽闲到框架里面实现部分吧？不然都依赖程序员自己去搞，会有点不可靠。
广州-Ryan(-) 18:25:21
嗯，做个小工具，你依赖hystrix我理解也是类似的东西。
广州-小护士<-> 18:26:36
所以就出现了 Service Mesh 架构。。就是为了解决你们两刚才说的问题.

3. [讨论]具备架构师头衔的人并不一定是架构师<聊聊架构[书]>.

北京-喜<-> 20:51:08
架构师拿结果比较难，因素多而复杂。 所以做偏C架构的居多，是因为这部分可以通过量化和抓手验证。只做偏C的部分，算不算架构师呢，见仁见智这个.
深圳-平凡(-) 21:51:46
c架构是什么？
北京-喜<-> 21:53:13
稳定性、可用性等主题有关
深圳-平凡(-) 22:01:09
我理解的架构是创建及维护软件结构体系的生命周期
北京-喜<-> 22:30:06
我理解架构是使得系统尽可能的不易变，建立稳固的关系, 稳定和不易变接近, 不管是熔断、降级，核心非核心梳理。还是一定程度的分层和多数据结构, 都是为了建设一个稳固的部分或关系, 其实是一段时间内看起来、处于某种稳固。稳固随着维护，可能会被打破.
深圳-平凡(-) 22:39:15
这个稳定性是架构原则吧。好比如设计模式6大原则，23种设计模式都是围绕着一到多种设计原则展开的。那是因为结构体系变了，所以需要重新完善这个结构体系。目标架构就是一个理想化的结构体系，你在从基线架构演进到目标架构过程中，演进路线很难一成不变。
北京-喜<-> 22:49:25
场景都有, 一种是原来的不稳定节点和场景解决了，次要问题上升. 一种是新业务加入, 一种是新依赖/链路加入, 链路和业务逻辑2个大方向, 偏C指的是链路部分, 平台化、中台化，指的是业务逻辑, 你可以先抛个你熟悉的架构模式或者方法论?
深圳-平凡(-) 23:01:57
稳定性在架构层面不属于原则，原则是偏落地了。应该属于架构愿景.
北京-喜<-> 23:03:02
终极目标基本是不存在的，这个是矛盾的
深圳-平凡(-) 23:03:49
在一定的时间 空间 范围内是存在的。
北京-喜<-> 23:03:54
终极目标假如达到了，说明业务场景/复杂度/流量等 是已可见的, 所以要加时间线, 如果业务场景/复杂度/流量等 是已可见的，那么用现有架构撑着也可以，就不必演进了
深圳-平凡(-) 23:05:01
就像国家的五年计划，国家每五年制定一次各行各业五年发展规划，指导行业五年内的落地。 时间 ：五年 空间：特定行业
北京-喜<-> 23:05:31
是的, 所以都会讲历史、现在、未来，3个时窗, 未来 一般不会超过3年, 比如我一直很倾向面向对象和设计模式在：就是因为可以建立一个稳固关系接口、扩展点和伸缩能力。DDD同理。 这部分是单一应用内, 其他的架构理念和方法论，多是链路的，偏集成场景.
深圳-平凡(-) 23:11:50
链路怎么理解？
北京-喜<-> 23:11:59
服务化产生的, 多系统调用、协作. 服务化是为啥? 放在1个系统内有啥问题?
深圳-平凡(-) 23:16:32
复用企业IT资产
北京-喜<-> 23:17:28
是因为太易变了，达到不可控、不可预期的程度了
深圳-平凡(-) 23:18:04
说起服务化，想起西神下午发的 thomas erlSOA架构。微服务架构也是由SOA演化而来，而现在宣传的微服务架构很欠缺服务资产治理。 thmoas erl的书籍都是围绕着这个讲的
北京-喜<-> 23:19:37
服务化 是圈出来一个个边界。 多个服务协作。 代替原来的单应用. 对相同的1个业务操作，服务化之后的，比原本的稳固的多。 不再是那么易变. 我说的是1个应用 到 多应用的过程/背景. 服务化和集成 带入新的风险. 风险 就是不可空/难预期, 所有偏C架构(高性能除外)的部分，都是控制这个风险. 让链路看起来是稳固的.
广州-Galen(-) 23:23:40
链路长，维护成本高.

2017-11-28

• 摘要: 无.

2017-11-29

• 摘要: 无.

1. 你们用Redis的时候，都碰到哪些应用场景了？[上海-雪驹]

2017-11-30

• 摘要: 敏感词过滤. 枚举. 秒杀.

1. im 过滤 一般都怎么做的, 比如说 QQ 有些词汇就发不出去, 这样的功能? [西咸-S]

广州-小护士<-> 10:17:54
正则+敏感词库
北京-喜<-> 10:18:52
我只知道用Trie树
广州-小护士<-> 10:20:47
匹配范围写大了，误杀就大了
西咸-S(-) 10:21:01
网上看的基本上都是基于 DFA 算法写的. 我在做操，你妈让我告诉你XX , 这个次理论上没问题~但是很多就误杀了.
广州-小护士<-> 10:22:10
DFA 有限状态机。。状态机那种是文法解析的思路。。玩得有点深.
杭州-beBetter(-) 10:22:53
是啊，Trie树比较快
北京-coder-在线教育(-) 10:23:02
误杀就误杀呗

2. 内存占用方面，这俩是哪个占用的大? [北京-C_C]

北京-Easy哥(-) 14:45:13
基本上没区别 ,个人推荐 用枚举
北京-C_C(-) 14:45:46
为啥, 我前老大是说能不用枚举就不用
北京-Easy哥(-) 14:45:57
代码洁癖 , 枚举好看一些 ,别听你老大的 , 枚举的话 jvm会有特殊的优化 尤其是在switch的时候. 另外hotspot会在比较的时候把枚举当int来比较, 所以, 通过switch来做分支处理的时候 比对象的比较快很多.不过 这个 可以不知道 但是。。。。枚举写的代码好看,这个也是很大的优势.
一些奇技淫巧不知道 没问题,但是怎么写代码好看, 这个更重要吧.
成都-勇(-) 14:49:53
单就那个图得话，枚举应该占内存大些.
北京-Easy哥(-) 14:50:26
差不多啊 因为 枚举编译后 和下面的是一样的,所以 内存上 没有啥优劣.
成都-勇(-) 14:56:19
枚举 的可读性，可扩展性更好，没有必要为了这么一点点内存牺牲它.
北京-Easy哥(-) 14:56:32
一般人我们说他们技术好 其实 是考察了 技术的广度和深度结合来说的 ,但是 还有一种技术好 是完完全全的技术深度 ,这样的人需要特殊的工作背景, 一般都是做底层组件的, 90%的技术人员 其实都是上面个 .
成都-勇(-) 14:59:44
有没有可能只有深度而没有广度，我感觉如果要足够深，感觉只专一门是不行得样。
北京-Easy哥(-) 15:01:19
这个广度是说 比如说 一个懂JVM技术 但是 他也懂数据库 也懂特殊的业务 也懂项目管理, 不是是只懂 JVM技术,但是编译原理,操作系统,网络就不懂了
成都-勇(-) 15:02:02
哦，明白了
北京-Easy哥(-) 15:02:04
因为这样的话, 他的jvm技术也一般, 就像说一个人精通java, 他至少要精通几门语言.

3. 这里介绍的，秒杀流程. [成都-梅小西]

北京-喜<-> 20:10:10
那不大家看到页面之后，都可以点击到“购买”走2的流程呢, 扯淡
成都-梅小西(-) 20:13:00
库存放缓存，用户下单，创建初始订单，发送修改库存的消息，接收消息，排队更新缓存, 貌似这流程, 更新缓存成功，修改订单状态
北京-喜<-> 20:14:08
流量都打给购买的服务了,然后只有一部分能秒杀成功。 前置没流量拦截, 部分能秒杀成功的依据是库存系统有没有库存。 也就是同样的流量从订单给了库存一份.
深圳-Mt<-> 20:24:29
秒杀不就一个redis Incr命令搞定吗, 限流, 保证应用和redis不挂
成都-梅小西(-) 20:26:45
我有个问题，压测的环境是线上环境的真实copy么
北京-Easy哥(-) 20:26:58
是的 真实copy
成都-梅小西(-) 20:27:38
db的数据量呢，难道一样？
北京-Easy哥(-) 20:27:51
影子库啊
北京-jax(-) 20:27:18
其实一直不明白压测怎么测？不要嫌弃我
杭州－东子(-) 20:31:28
首先并不是所有功能都要压测, 一般是新上的功能, 或者是影响分析做完了决定要压测的, 新系统来了或者新功能, 新系统就选择登陆退出和主要关键交易.

2017-12-01

• 摘要: 令牌.

1. 问一下，令牌，你们用什么来实现?[中山-划船]

中山-划船(-) 14:32:49
redis？
成都-梅小西(-) 14:33:11
token？ 不一定，数据库也可以啊
珠海-可乐<-> 14:34:14
你不是该问认证和授权用什么实现的？
中山-划船(-) 14:35:48
是限制访问量的
珠海-可乐<-> 14:36:30
那不是限流嘛, ratelimiter用redis或者guava，单机用guava也行，集群用redis