红色有角F叔对《微服务设计》的笔记(10)

红色有角F叔
红色有角F叔 (次元の呪い)

读过 微服务设计

微服务设计
  • 书名: 微服务设计
  • 作者: [英] Sam Newman
  • 页数: 228
  • 出版社: 人民邮电出版社
  • 出版年: 2016-5
  • 演化式架构师
    在我们的行业中,这种建筑师的视角会导致一些非常糟糕的实践。人们试图通过大量的图标和文档创建出一个完美的方案,而忽视了很多基础性的未知因素。
    城市规划师应该尽量去预期可能发生的变化,但是也需要明白一个事实:尝试直接对各个方面进行控制往往不会奏效。
    未来的变化很难预见,所以与其对所有变化的可能性进行预测,不如做一个允许变化的计划。为此,应该避免对所有事情做出过于详尽的设计。
    2016-06-09 11:44:37 回应
  • 一个原则性方法
    一般来讲,原则最好不要超过 10 个,或者能够写在一张海报上,不然大家很难记住。
    实践应该巩固原则。
    有些东西对一些人来说是原则,对另一些人来说则可能是实践。比如,你可能会把使用 HTTP/REST 作为原则,而不是实践。这也没什么问题,关键是要有一些重要的原则来指导系统的演化,同时也要有一些细节来指导如何实现这些原则。对于一个足够小的群组,比如单个团队来说,将原则和实践进行结合是没有问题的。但在一个大型组织中,技术和工作实践可能不一样,在不同的地方需要的实践可能也不同。不过这也没关系,只要它们能映射到相同的原则即可。比如一个 .net 团队可能有一套实践,一个 java 团队有另一套实践,但背后的原则是相同的。
    2016-06-09 11:48:48 回应
  • 代码治理
    聚在一起,就如何做事情达成共识是一个好主意。但是,花时间保证人们按照这个共识来做事情就没那么有趣了,因为在各个服务中使用这些标准做法会成为开发人员的负担。我坚信应该使用简单的方式把事情做对。我见过比较奏效的两种方式是,提供范例和服务代码模板。
    编写文档是有用的,... 但是开发人员更喜欢可以查看和运行的代码。
    创建服务代码模板不是某个中心化工具的职责,也不是指导我们应怎样工作的架构团队的职责。应该通过合作的方式定义出这些实践,所以你的团队也需要负责更新这个模板。
    我也见过一个团队的士气和生产力是如何被强制使用的框架给毁掉的。基于代码重用的目的,越来越多的功能被加入到一个中心化的框架中,直到把这个框架变成一个不堪重负的怪兽。
    你还需要知道,重用代码可能引入的危险。在重用代码的驱动下,我们可能会引入服务之间的耦合。... 一些我接触过的团队,把服务代码模板简单地做成了一个共享的库依赖,这时他们就要非常小心地防止对 DRY 的追求导致系统过度耦合。
    2016-06-09 11:59:27 1人推荐 回应
  • 集中治理和领导
    架构师的部分职责是治理。那么治理又是什么意思呢?COBIT (Control Objectives for Information and Related Technology)给出了一个很好的定义:治理通过评估干系人的需求、当前情况以及进一步的可能性来确保企业目标的达成,通过排优先级和做决策来设定方向。对于已经达成一致的方向和目标进行监督。
    架构师会对很多事情负责。他们需要确保有一组可以指导开发的原则,并且这些原则要与组织的战略相符。他们还需要确保,以这些原则为指导衍生出来的实践不会给开发人员带来痛苦。他们需要了解新技术,需要知道在什么时候做怎样的取舍。上述这些职责已经相当多了,但是他们还需要让同事也理解和决定这些取舍,并执行下去。对了,还有前面提到的:他们需要花时间和团队一起工作,甚至是编码,从而了解所做的决定对团队造成了怎样的影响。
    你没法替代他们去骑车。你会看着他们摇摇晃晃地前进,但是如果每次你看到他们要跌倒就上去扶一把,他们永远都学不会。而且无论如何,他们真正跌倒的次数会比你想象的少。但是,如果他们马上就要驶入车流繁忙的大马路,或者附近的鸭子池塘,你就必须站出来了。类似地,作为一名架构师,你必须要在团队驶向类似鸭子池塘这样的地方时抓紧他们。
    还有一点要注意的是,即使你很清楚什么是对的,然后尝试去控制团队,也可能会破坏和团队的关系,并且会使团队感觉他们没有话语权。有时候按照一个你不同意的决定走下去反而是正确的,知道什么时候可以这么做,什么时候不要这么做是很困难的,但有时也很关键。
    2016-06-09 12:42:02 回应
  • 建设团队
    帮助别人成长的形式有很多种,其中大部分都超出了本书的范围。微服务架构本身能够提供一种很好的形式。在单块系统中,人们对某些事情负责的机会非常有限,而在微服务架构中存在多个自治的代码库,每个代码库都有自己独立的生命周期,这就给更多人提供了对单个服务负责的机会,而当这些人在单个服务上得到足够锻炼之后,就可以给他们更多的责任,从而帮助他们逐步达成自己的职业目标,同时通过分担职责也可以防止某一个人的负担过重。
    我坚定地相信,伟大的软件来自于伟大的人。所以如果你只担心技术问题,那么恐怕你看到的问题远远不及一半。
    2016-06-09 12:45:18 回应
  • 技术边界
    这个组织逐渐决定对团队进行扩容,增加了一个巴西团队来分担一部分工作。系统被划分成两部分,一部分面向前端,该部分不保存任何状态,如图 3-4 所示;后端部分就是一个简单的数据存储,通过 RPC 提供服务。基本上你可以理解为,把一个代码库中的仓储层变成了一个独立的服务。 后来发现,需要频繁地同时修改两个服务。两个服务都是偏底层的、RPC 风格的方法调用,而这是非常不稳定的。这个服务接口也很繁琐,会导致性能问题。这就导致了对 RPC 批处理的需求。我把这种架构称为洋葱架构,因为它又很多层,而且当纵切这些层次时,我只想哭。
    2016-06-09 14:36:23 1人推荐 回应
  • 客户端库
    如果开发服务端 API 和客户端 API 的是同一批人,那么服务端的操作逻辑就有可能泄露到客户端中。.. 潜入到客户端的逻辑越多,内聚性就越差,然后你必须在修复一个服务端问题的同时,也需要对多个客户端进行修改。
    2016-06-09 15:51:48 回应
  • 特性团队
    特性团队(基于特性开发的团队)的想法,是一个小团队负责开发一系列特性需要的所有功能,即使这些功能需要跨组件(甚至服务)的边界。
    许多情况下,特性团队是对传统的 IT 组织中,团队结构围绕技术边界进行组织的一种修正。例如,你可能有一个团队专门负责用户界面,另一个团队负责应用程序逻辑,第三个团队负责处理数据库。这种环境下,特性团队迈出了一大步,它跨越所有层提供完整的功能。
    大范围地采用特性团队后,所有服务都是共享的。
    2016-06-11 11:44:55 回应
  • consul
    consul 底层的 serf 可以处理集群中的节点检测、故障管理和报警。然后 consul 在其之上添加了服务发现和配置管理。
    2016-06-13 09:19:06 回应
  • 单点登录网关
    这种方法的最后一个问题是,它会给你一种虚假的安全感。我喜欢深度防御的理念,从网络边界,到子网,到防火墙,到主机,到操作系统,再到底层硬件。
    网关层承担越来越多的功能后,最终本身会是一个庞大的耦合点。
    网关可以提供相当有效的粗粒度的身份验证。例如,它可以阻止任何未登录用户访问帮助台应用程序。
    你应该倾向于使用粗粒度的角色,围绕组织的工作方式建模。
    2016-06-13 10:18:30 回应

红色有角F叔的其他笔记  · · · · · ·  ( 全部654条 )

注定一战
1
美国反对美国
1
哲学·科学·常识
1
计算机组成(第 6 版)
2
图解TCP/IP(第5版)
1
沸腾十五年
2
重新理解创业
8
雄性衰落
3
股市真规则
1
资本和收入的性质
2
存在主义是一种人道主义
3
程序员的职业素养
1
何为良好生活
1
活出生命的意义
3
货币的教训
3
Docker——容器与容器云(第2版)
2
政治的人生
4
中国巨债
3
深入浅出React和Redux
5
历史的教训
4
聪明的投资者
8
Designing Data-Intensive Applications
4
投资中最简单的事
5
供给的逻辑
1
逃不开的经济周期
1
图解服务器端网络架构
1
斯坦福极简经济学
3
政治的逻辑
4
原则
5
大数据之路
1
在苍茫中传灯
4
巴菲特传(纪念版)
1
中产阶级如何保护自己的财富
1
指数基金投资指南
4
模式分类
2
深度学习
1
我看电商
2
数据挖掘导论
1
中国国家治理的制度逻辑
2
漫步华尔街
2
尽在双11:阿里巴巴技术演进与超越
2
共同基金常识
3
企业IT架构转型之道:阿里巴巴中台战略思想与架构实战
6
未来简史
2
MySQL DBA修炼之道
1
大国大城
2
计算广告
4
机器学习
1
集体智慧编程
1
重新定义公司
1
Hadoop应用架构
1
第二性
6
硅谷钢铁侠
1
大数据
5
经营的本质
1
人人都是产品经理
7
你凭什么做好互联网
4
Spark机器学习
2
聊聊架构
8
游戏引擎架构
1
美国大城市的死与生(纪念版)
5
给大家看的Photoshop讲座
1
技术的本质
5
我们房地产这些年
2
行动的勇气
2
合作的进化
5
马克斯·韦伯与德国政治:1890—1920
6
数据库索引设计与优化
1
精益企业
7
高可用MySQL
2
发布!软件的设计与部署
2
项目管理艺术
2
右派国家
5
现实感
4
领域驱动设计
11
从0到1
1
高效程序员的45个习惯
1
可扩展的艺术
3
空之境界 上
1
成为技术领导者
1
改革的逻辑
3
修改代码的艺术
9
恰如其分的软件架构
7
软件开发者路线图
3
实现领域驱动设计
1
21世纪资本论
9
持续交付
16
构建之法
6
黑格尔导论
19
极端的年代
1
Site Reliability Engineering
5
测试驱动的面向对象软件开发
3
城市的胜利
2
对知识的恐惧
5
ZeroMQ
6
现代经济学主要流派
7
数学之美
2
程序员的思维修炼
1
大教堂与集市
1
一切坚固的东西都烟消云散了
5
兜售繁荣
1
数据科学与工程技术丛书
1
政治的细节(第10版)
8
发展研究指南(第二版)
2
代码大全(第2版)
2
企业应用架构模式
9
The Datacenter as a Computer
3
无情的革命
6
新教伦理与资本主义精神
3
人类简史
7
Understanding MySQL Internals
2
他改变了中国
1
态度改变与社会影响
4
复杂
2
民主新论
19
人件
2
国家的常识
4
乌合之众
3
Web Operations
2
个人印象
4
湖上闲思录
2
自由及其背叛
7
C++语言的设计与演化
8
百年中国经济史笔记
1
改变
4
创新与企业家精神
5
Cassandra
3
不敢止步
4
意志力
2
通向财务自由之路
1
制造同意
6
美国种族简史
4
NoSQL Distilled
4
理解专业程序员
2
一个自由主义者的良知
4
政治经济学要义
2
施瓦辛格健身全书
2
房地产的繁荣与萧条
5
为学十六法
2
Akka in Action
1
Java虚拟机并发编程
3
软件工艺
3
面向模式的软件架构,卷3
1
动物精神
4
非理性繁荣
10
MongoDB权威指南
2
海量数据库解决方案
1
Erlang/OTP并发编程实战
1
学术与政治
12
Java并发编程实战
16
论中国
3
金融炼金术
4
多处理器编程的艺术
1
Effective java 中文版(第2版)
1
中國近代史(下冊)
6
系统之美
6
压力下的角逐
2
古代东方史
1
Go 语言程序设计
1
Remote
1
深入Linux内核架构
2
中國近代史(上冊)
3
隐秩序
1
空之境界(上下集合售)
1
开放社会
4
中国近代史八种
5
喀提林阴谋 朱古达战争
1
政治秩序的起源
5
现代性的后果
2
失去的胜利
9
了不起的盖茨比
5
许倬云说历史:台湾四百年
2
大规模分布式存储系统
1
C++网络编程(卷1)
2
在约定的场所
1
中国的宗教
2
了不起的盖茨比
1
希腊罗马名人传(全三册)
2
自私的基因
2
学龠
1
中国政治思想史
4
列克星敦的幽灵
1
人月神话
2
现代体系结构上的UNIX系统
1
虚拟机
2
朱熹的历史世界
1