> 202年01月23日信息消化 ### Scaling the Practice of Architecture, Conversationally > MEMO > > 去中心化的架构：任何人都可以提出，利益相关者与领域专家分别进行评估个。 > 注意：区分架构与实践。比如遵循TDD不是架构原则考虑的范畴。 origin: [Scaling the Practice of Architecture, Conversationally](https://martinfowler.com/articles/scaling-architecture-conversationally.html#4.ATechLandscapeAndCurrentClimateSensingTool-YourOwnTechRadar) Architecture need not be a monologue; delivered top-down from the minds and mouths of a centralised few. This article describes another way to do architecture; as a series of conversations, driven by a decentralised and empowering decision-making technique, and supported by four learning and alignment mechanisms: Decision Records, Advisory Forum, Team-sourced Principles, and a Technology Radar 建筑不必是独白；从集中的少数人的思想和口中自上而下地传递。这篇文章描述了另一种做架构的方法；作为一系列对话，由分散和授权的决策技术驱动，并由四种学习和协调机制支持：决策记录、咨询论坛、团队来源的原则和技术雷达 #### When "traditional" approaches to architecture break down I'll be honest, “traditional” approaches to software architecture (i.e. non-coding, decision-taking, diagram-drawing) are hard for me to make work at the best of times. But while using them in the world of continuously delivering autonomous teams I’ve repeatedly found myself faced with an impossible task: to be everywhere, tolerating significant contextual variance, and blocking no-one. 老实说，软件架构的“传统”方法（即非编码、决策、图表绘制）对我来说很难在最好的时候完成工作。但是，在持续交付自主团队的世界中使用它们时，我反复发现自己面临着一项不可能完成的任务：无处不在，容忍显着的上下文差异，并且不阻止任何人。 It made me wonder. Was there an alternative? There was: I stopped taking architectural decisions. Completely. In this article I’ll introduce this alternative mindset and the associated set of tools and practices which allow me to upend the traditional role of a “Software Architect” while simultaneously bringing the practice of software architecture to the fore across development teams. More importantly, I’ll explain how, within this alternative approach, everyone can do the architecting they need, safely and efficiently, without everything descending into chaos. 在本文中，我将介绍这种替代思维方式以及相关的工具和实践集，这些工具和实践使我能够颠覆“软件架构师”的传统角色，同时将软件架构的实践带到开发团队的前沿。更重要的是，我将解释如何在这种替代方法中，每个人都可以安全有效地完成他们需要的架构，而不会让一切陷入混乱。 What we need is a workable way to approach the human-scaling challenges of team autonomy and the architectures which manifest as a result. 我们需要的是一种可行的方法来应对团队自治的人类规模挑战以及由此产生的架构。In the remainder of this article I’ll introduce an alternative way of doing and governing architecture. I’ll explain in detail what it is, how it works, and how you might adopt it yourself. Most importantly, I’ll highlight how to fail, in order that you might succeed. #### The most fundamental element: decision-making via the “Advice Process” These architectural decisions must still be made deliberately - otherwise we’ll be back where we started, or worse. Therefore, the first aspect in this alternative approach, it’s core element in fact, must describe how it delivers on decision-making. It’s called the “Advice Process”. The Advice Process is the core element of this anarchist, decentralised approach to architecture. It’s greatest quality is it’s remarkably simplicity. It comprises one rule, and one qualifier: **The Rule:** anyone can make an architectural decision. **The Qualifier:** before making the decision, the decision-taker must consult two groups: The first is everyone who will be meaningfully affected by the decision. The second is people with expertise in the area the decision is being taken. 建议流程是这种无政府主义、分散式架构方法的核心要素。它最大的品质是非常简单。它包含一个规则和一个限定符： 规则：任何人都可以做出架构决策。 限定者：在做出决定之前，决策者必须咨询两组人：第一组是会受到该决定有意义影响的每个人。第二个是在该领域具有专业知识的人正在做出决定。 A challenge frequently raised against this concerns just how many people must be consulted. It is a valid concern, but a mitigatable one. When deploying this technique we create a checklist to help those in the decision-making seat identify who to speak to, and in which regard. InfoSec impacted? Talk to the CISO. Getting close to PII? Engage Mary in the data team and Vanessa in legal. A potential change to the user onboarding flow? Talk to your UX lead. About to adopt a new cloud service? Chat to Kris the cloud architect. Thinking about a change to your API? Speak to all the leads of the teams who are your consumers. 针对这一问题经常提出的挑战是必须咨询多少人。这是一个有效的担忧，但可以缓解。在部署这项技术时，我们创建了一个清单，以帮助决策席位上的人确定与谁交谈，以及在哪方面交谈。信息安全受到影响？与 CISO 交谈。接近 PII？让 Mary 参与数据团队，让 Vanessa 参与法律。用户入职流程的潜在变化？与您的 UX 负责人交谈。即将采用新的云服务？与云架构师 Kris 聊天。考虑更改您的 API？与作为您的消费者的团队的所有领导交谈。 Which brings us to the broader topic of benefits of the Advice Process. When deployed, I have always seen better, faster, more accountable decisions, and most importantly decisions which are understood and owned by those who implement them, precisely because the decidee is the one with the need as well as the one who is accountable. As a side-effect, the pool of available decision-takers also grows, each of whom will soon be on the look-out for decisions which need to be made, and, given the feeling of empowered safety that the Advice Process gives them, flag them up and drive them to conclusion. The fact that a team's need for a decision to be taken can be met by themselves also leads to appropriate levels of bias-to-action, with accountability acting as a brake when it's required. 作为一个副作用，可用决策者的数量也在增加，他们中的每个人很快都会留意需要做出的决定，并且考虑到建议流程给他们的安全感，标记他们并推动他们得出结论。一个团队需要做出决定的需要可以由他们自己来满足，这一事实也导致了适当程度的行动偏见，在需要时，问责制起到了刹车的作用。 By working in this way we remove both the need for a fixed and permanent hierarchy and an abiding master decision-taker. It is for these two reasons that the Advice Process is the most fundamental element of this approach to architecture, because decentralised decision-making is the core element of anything which aspires to call itself “anarchistic”. By working in this way we remove both the need for a fixed and permanent hierarchy and an abiding master decision-taker. It is for these two reasons that the Advice Process is the most fundamental element of this approach to architecture, because decentralised decision-making is the core element of anything which aspires to call itself “anarchistic”. 通过以这种方式工作，我们消除了对固定和永久层次结构和持久的主要决策者的需求。正是由于这两个原因，建议流程是这种架构方法中最基本的元素，因为去中心化的决策是任何渴望称自己为“无政府主义”的事物的核心元素。1. A thinking and recording tool: Decision Records #### The Four Supporting Elements ##### 1. A thinking and recording tool: Decision Records The first supporting element is [Architectural Decision Records](https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records) or ADRs. These are lightweight documents, frequently stored in source code repositories alongside the artefacts they describe. Now, there are a variety of formats which various adopters have chosen to champion, but the key elements which I insist on are as follows: [[4\]](https://martinfowler.com/articles/scaling-architecture-conversationally.html#footnote-two-more) | name | description | | :----------------- | :----------------------------------------------------------- | | title | which includes a unique identifier, and the decision itself (e.g. “ADR001 - Use AKS for Kubernetes Pods”) | | status | typically “Draft”, “Proposed”, “Adopted”, “Superseded” and “Retired” | | decision | the decision that has been taken in a few sentences (frequently bold or italicized so it stands out) | | context | the forces and current contextual circumstances which have necessitated this decision | | options considered | each option considered, described briefly, with pros and cons. (Typically the option proposed / adopted comes first in this list) | | consequences | the ramifications of this decision, both positive and negative | | advice | this reflects the raw outputs from following the Advice Process. It is here that all advice given is recorded. This ought to include the name of the advice giver, and the date the advice was given. This can frequently take the forms of comments, and if these are provided directly by the advice-giver, then recording the meta-data is automatic. | ### 2. A time and place for conversations: The Architecture Advisory Forum The standing agenda typically begins as follows: - team representatives quickly share new [spikes](http://www.extremeprogramming.org/rules/spike.html) (giving early warning of probable future decisions and allow the attendees to share existing knowledge and experience) - discussions about each new “proposed” decision (presented by those making the decision, captured ahead of time in the form of an ADR) - a re-visit of other decision-statuses (we timebox these, both to limit the window for incoming advice, and also to allow us to revisit a decision which we made with imperfect information) - a look at our collective four key metrics, our cloud spend trends, and finally - any other business (aka “AOB”) ### 3. A light to illuminate a unified goal: Team-sourced Architectural Principles So what makes a good architectural principle? Firstly, it must provide a **criteria** with which to **evaluate our architectural decisions** (which in practice means it must be specific, measurable, achievable, realistic and testable, aka “S.M.A.R.T”). Secondly, it must support the **business’s strategic goals**. Thirdly, it must articulate the consequences / implications it necessarily contains within it. Finally, taken together as a set, they should number neither too few to cover the key needs which architectural principles meet, nor too many that teams cannot remember them all. So what makes a good architectural principle? Firstly, it must provide a criteria with which to evaluate our architectural decisions (which in practice means it must be specific, measurable, achievable, realistic and testable, aka “S.M.A.R.T”). Secondly, it must support the business’s strategic goals. Thirdly, it must articulate the consequences / implications it necessarily contains within it. Finally, taken together as a set, they should number neither too few to cover the key needs which architectural principles meet, nor too many that teams cannot remember them all. There is a great deal I could write here about bad architectural principles but I’ll stick to the key aspects. Firstly, they are not practices. Practices are how you go about something, such as following TDD, or Trunk Based Delivery, or Pair Programming. This is not to say that practices are bad (indeed Dr Forsgren’s “Accelerate” is full of recommendations regarding for their set of circumstances) they’re just not architectural principles. 我可以在这里写很多关于糟糕的架构原则的文章，但我会坚持关键方面。首先，它们不是实践。实践是你做某事的方式，例如遵循 TDD、基于主干的交付或结对编程。这并不是说实践不好（事实上，Forsgren 博士的“加速”充满了针对他们所处环境的建议）它们只是不是架构原则。 Watch out for slipping into the other end of the scale too - general principles. “Keep it simple” and “Don’t repeat yourself” are principles, but they’re not architectural. Nor are the various principles you’ll see around project planning, and software quality management. What we need are means to direct and evaluate our architectural practice and decisions. What we need is something which helps me pick between [various approaches to implementing micro-frontends](https://martinfowler.com/articles/micro-frontends.html#IntegrationApproaches), or helps me decide if it really makes sense to [hand-roll my own OAuth 2.0 implementation](https://frontend.turing.edu/lessons/module-4/oauth/index.html#OSP), or guides me in evaluating self-hosted [Lucene](https://lucene.apache.org/) on AWS vs [Amazon Elastic Search Service](https://aws.amazon.com/elasticsearch-service/). 小心滑入天平的另一端——一般原则。 “保持简单”和“不要重复自己”是原则，但它们不是架构性的。您也不会看到围绕项目规划和软件质量管理的各种原则。我们需要的是指导和评估我们的架构实践和决策的方法。我们需要的东西可以帮助我在实现微前端的各种方法之间进行选择，或者帮助我确定手动实现我自己的 OAuth 2.0 是否真的有意义，或者指导我评估 AWS 和 Amazon 上的自托管 Lucene弹性搜索服务。 Given all this, now let’s share a good principle, based around the Team Topologies [“Stream-Aligned Team”](https://teamtopologies.com/key-concepts) organisation model: ```text Title: Value independence of teams most highly Subtitle: Split solutions along team lines Rationale: The strength of our approach to building and running our products relies fundamentally on the independence of our teams. The downsides to this are acknowledged, but the upsides are felt to outweigh it, especially when the difficulty of predicting future needs is taken into consideration. Implications: Duplication of both function, and data, will inevitably arise. Rather then fight this, we embrace it, acknowledging the need, in certain circumstances, for noticeable eventual consistency and data replication The combined licencing, runtime and support costs of multiple third-party solutions may be higher than the costs of a single, shared, cross-product-team solution Solutions can be designed for the needs of the team which owns and runs them. They need not concern themselves the needs of other teams Both systems and the third-party services / solutions they are build on will tend to be smaller, and more specific-task-focussed Teams who go their own way need to self-support any third-party services / solutions which they adopt independently ``` If you want to see more examples, please have a look at the publicly-available [John Lewis “Software Engineering Principles”](http://engineering-principles.onejl.uk/). [[5\]](https://martinfowler.com/articles/scaling-architecture-conversationally.html#footnote-jl-non-principles) ### 4. A tech landscape and current climate sensing tool - Your own Tech Radar Many people have heard of the ThoughtWorks [Technology Radar](https://www.thoughtworks.com/radar) - an opinionated guide to current trends (predicted, current, and receding) in software languages and frameworks, tools, platforms, and techniques. It’s strengths lie in how it visually represents both the current landscape and the movements of various “blips” across it, allowing viewers to very rapidly see (for example) what is up and coming in the world of front-end frameworks, what’s current flavour of the month, and what’s beginning to fade. 许多人都听说过 ThoughtWorks 技术雷达 - 一个关于软件语言和框架、工具、平台和技术的当前趋势（预测、当前和后退）的固执己见的指南。它的优势在于它如何在视觉上代表当前的景观和各种“光点”的运动，让观众能够非常快速地看到（例如）前端框架世界中正在发生的事情，当前的风格是什么这个月，什么开始消退。 ### 我并没有选择node.js做cli而投靠了golang。 > MEMO > 倒是不太在意实际性能问题，以前觉得nodejs 开发热加载特别慢，最近试了withfig/autocomplete时，几乎同时就加载完了...js的生态太强大了。。 origin: [和大多数的前端开发者相比，我并没有选择node.js做cli而投靠了golang。](https://juejin.cn/post/7057178581897740319) #### 流写入 ##### golang ```golang func main() { file, _ := os.OpenFile("./go.txt", os.O_CREATE|os.O_RDWR|os.O_APPEND, 0777) defer file.Close() ws := bufio2.NewWriter(file) i := 0 for i < 100000 { ws.WriteString("a\n") i++ } ws.Flush() } ``` ``` real 0m0.167s user 0m0.251s sys 0m0.094s ``` ##### js ```js const fs = require('fs') let i = 0; ws = fs.createWriteStream("node.txt") //5个零 while (i < 100000) { ws.write("a\n") i++; } ws.end() ``` ``` real 0m2.397s user 0m0.156s sys 0m0.398s ``` 在这次的编码中我选择了golang著名cli开源库`cobra` [cobra](https://link.juejin.cn?target=http%3A%2F%2Fgithub.com%2Fspf13%2Fcobra)是一个命令行程序库，可以用来编写命令行程序。同时，它也提供了一个脚手架， 用于生成基于 cobra 的应用程序框架。非常多知名的开源项目使用了 cobra 库构建命令行，如[Kubernetes](https://link.juejin.cn?target=http%3A%2F%2Fkubernetes.io%2F)、[Hugo](https://link.juejin.cn?target=http%3A%2F%2Fgohugo.io%2F)、[etcd](https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2Fcoreos%2Fetcd)等等等等。 本文介绍 cobra 库的基本使用和一些有趣的特性。 #### 快速使用 ```bash go get -u github.com/spf13/cobra/cobra # -u 安装全局变量类似npm i -g cobra cobra init appname cd appname && go mod init appname ``` 我们拥有的项目结构 ``` appname/ ▾ cmd/ helper.go root.go version.go main.go 复制代码 ``` ##### 添加更多的命令 ``` cobra add time ``` 会在cmd文件夹添加一个命令文件。 ```golang /* Copyright © 2022 NAME HERE <EMAIL ADDRESS> */ package cmd import ( "log" "os" "os/exec" "github.com/spf13/cobra" ) // timeCmd represents the time command var timeCmd = &cobra.Command{ Use: "time", Short: "计算时间用的", Long: `其实是一个dome`, Run: func(cmd *cobra.Command, args []string) { //主要关注这里，执行的调用 c := exec.Command("bash", "-c", "time ls") c.Stdout = os.Stdout c.Stderr = os.Stderr err := c.Run() if err != nil { log.Println(err) } }, } func init() { rootCmd.AddCommand(timeCmd) } ``` ### [v2ex](https://www.v2ex.com/t/829521) | Node 是如何应对高并发场景的？答：异步非阻塞。 > Node 是如何应对高并发场景的？答：异步非阻塞。 > > JavaScript 的生态根基简单来讲就是语言+API 。 > JavaScript 是一门脚本语言，一门语言要想有实际用途就得有能力调用各个系统，那么就需要各个系统面向 JavaScript 提供 API ，比如你计算了 1+2 ，能得出结果 3 ，但你要想看到这个结果就得让操作系统帮你显示出来，于是操作系统（中间省略很多环节）给 JS 提供了个 console API ，你可以使用 console.log 来（中间省略很多环节）调用操作系统把 3 显示出来。 > > 所以 Node 不等于 JS ，JS 语言的执行能力只是 Node 的一项子功能而已。 > > 原生 JavaScript 语言是单线程执行的，但 Node 不是单线程的，Node 为 JS 语言提供了一些 API ，其中大部分都是 IO 相关的 API ，比如网络访问、文件系统访问等。 > > Node 有一个假设，就是很多应用场景下 IO 操作的工作量要远远大于计算操作。比如大多 Web 应用服务都是响应网络请求（ IO 操作），经过简单的逻辑计算，然后进行数据库请求（ IO 操作），那么假设只要 CPU 不闲着，IO 负载很可能会比 CPU 负载先用满。 > > Node 如何做到让 CPU 不闲着？答：计算单线程执行，IO 多线程执行（异步），但计算可以不等着 IO 完成（异步非阻塞）。 > > 不调用任何 API ，纯进行 JS 计算，比如算斐波那契数列，1+2=3,2+3=5……这个只能单线程执行，算 2+3=5 的时候必须等着 1+2 出结果，只不过此时 CPU 并没有闲着而已。 > 如果在计算出每一个数字的时候，把数字写到硬盘上，这个写硬盘的操作就是 IO 操作； > 假设没有异步非阻塞机制，应该是这样的：计算 1+2 ，得出 3 ，执行将 3 写入硬盘，等待写入完成，写入完成后计算 2+3……CPU 在等待的时候是闲着的，时间基本浪费在等待将 3 写入硬盘。 > 现在 Node 给你了一个能力，就是你可以在向硬盘写入 3 的时候选择不等着它完成，直接继续算 2+3 ，这就相当于有 1 个线程在不停算斐波那契数列，额外还有多个线程帮你把每个结果存硬盘。 > > 回到题主的场景描述，Node 接收到一个请求之后，如果进行简单逻辑计算后就直接操作数据库（ IO 操作）或应答（ IO 操作）的话，可以选择不等着 IO 操作完成，继续处理下一个请求，等某个 IO 操作完成了就会回来调用后续的 JS 程序。 > > 但如果执行的是异常复杂的计算，比如视频转码，如果是在处理请求的线程里做的话，一定会抢占预期用于处理请求的 CPU 时间，导致请求“卡住”。不过你猜怎么着，Node 其实是提供了多线程 API （ Worker threads ）和多进程 API （ Child process ），你完全可以像其他语言那样使用多线程和多进程来进行优化。除此之外 Node 还提供了面向 C/C++的 N-API 以及面向很多语言的 WebAssembly ，在需要极端计算性能的场景下不至于完全放弃 JS 技术栈。 ### Misc - [I automated my job over a year ago and haven't told anyone.](https://old.reddit.com/r/antiwork/comments/s2igq9/i_automated_my_job_over_a_year_ago_and_havent/) ([self.antiwork](https://old.reddit.com/r/antiwork/)) > Think of your wages as a subscription service to your automation program lol. > > Big companies love subscription services right - [Microsoft to Acquire Activision Blizzard](https://news.microsoft.com/2022/01/18/microsoft-to-acquire-activision-blizzard-to-bring-the-joy-and-community-of-gaming-to-everyone-across-every-device/) | [HN](https://news.ycombinator.com/item?id=29978723) > Comment > It's wild how Microsoft has been able to vertically integrate gaming. > > They now own the distribution (Xbox Cloud Gaming, Xbox Game Pass), the games (Call of Duty, WoW, Starcraft + what they owned before), the OS (Windows, Xbox), the hardware (Xbox, many PCs), and the back end compute (Azure). The only thing they're missing, the network bandwidth, is mostly a commodity anyway. > > That's a heck of a moat. - [The Anatomy of a Data Science Use Case](https://towardsdatascience.com/the-anatomy-of-a-data-science-use-case-4fba716eeb5a) - 4 components you must define in a use case before writing any piece of code -  - [I got pwned by my cloud costs (troyhunt.com)](https://news.ycombinator.com/item?id=30054739) > HN Comment > Don't put Cloudflare in front of a Cloud egress bill. i.e. don't do this: Azure|Amazon > Cloudflare > > Always use your own proxy where the egress is well within your free tier, i.e. do this: Azure|Amazon > Hetzner|Linode > Cloudflare > > Why? > > Because Cloudflare cache is a massively multi-tenant LRU cache and whilst hot files will be cached well (and with Cloudflare Tiered Cache even better - but this itself is a cost) anything else is still going to expose you to some degree of egress cost. > 因为 Cloudflare 缓存是一个大规模的多租户 LRU 缓存，而热文件将被很好地缓存（并且使用 Cloudflare 分层缓存更好 - 但这本身就是一种成本）任何其他东西仍然会让您承受一定程度的出口成本。 > > When I exposed AWS to the web I paid `$3k` per month to AWS. With Cloudflare in front of AWS I paid `$300` per month to AWS. With Linode in front of AWS and behind Cloudflare I paid `$20` per month to Linode and about $12 per month to AWS. > > A Linode, Hetzner instance... or any other dumb cheap web server that comes with a healthy free tier of bandwidth is all you need to set up a simple nginx reverse proxy and have it cache things to disk [https://docs.nginx.com/nginx/admin-guide/content-cache/conte...](https://docs.nginx.com/nginx/admin-guide/content-cache/content-caching/) - [Ask HN: What technology is “cutting edge” in 2022?](https://news.ycombinator.com/item?id=30053761) - For programming languages, **dependent types**. DT is a hot topic in the PL community recently. It massively enhances the capability of a type system by turning it into a comprehensive logic system, so you can encode whatever properties you'd like to enforce into a type signature. Theorem provers have been taking advantage of the Curry-Howard correspondence for some time, but the implication of DT on real-world programming is still not well understood (we need more real-world projects written in DT languages). There are also ambitious projects that want to bring DT into the mainstream. - https://leanprover.github.io/ - Interesting! 2 Years ago I was reading that there is exponential growth in **remote sensory data** (drones and satellite due to CubeSat and decreasing cost in lunching material into space.) Do you see growth in that area or where would you get more information about it? - **Zero-knowledge proofs**. Several major cryptographic achievements have been unlocked only in recent years, facilitating both privacy and efficiency for certain setups that were only theorized before. There’s still a lot to be done for developer tooling and libraries. The foundation is solid but the ecosystem is nascent.