作者 | 张羽辰（同昭）阿里云交付专家
导读 ：现在，简直所有的事件都离不开软件，当你开车时，脚踩上油门，实际上是车载计算机通过力度感应等计算输出功率，最终来管制油门，你从未想过这会是某个工程师的代码。
当咱们议论架构时，咱们到底在议论什么？
面向对象编程？函数式？模块化设计？微服务？这些词汇貌似都和架构这个 buzzword 有点关系，确实咱们这个畛域充斥了很多难以了解的词汇，这些词汇从英语翻译到中文曾经丢失了局部上下文，再随着上下文的扭转使得意义彻底扭曲，比方：引擎、框架、架构、利用、零碎……诚然大家都或多或少对这些词语达成共识，在工作中应用这些词汇进行沟通，某时就是指“咱们都懂的那个货色”，然而在我深刻的想聊聊架构或者说软件架构时，确实不得不问本人这个问题，咱们到底是议论什么？
事实上，架构这个词依据上下文所确定的范畴较为固定，建筑学上的架构指代房屋结构、整体设计、组合形成等，而这些 high-level 设计往往并不需要全面理解底层，就像应用 RestTemplate 进行 WebService 调用时，咱们也不关怀 socket 是在四层连贯的一样， 因为细节被暗藏了 。
然而，建筑学上的架构与软件架构却又极大的不同之处，问题呈现在“软件”这个词上，依照 software 的词解，ware 是指产品一样的货色，而 soft 则强调易变，这是与 hardware 所对应的。咱们心愿“软件”可能进行疾速的批改，应该可能疾速响应甲方或者客户的需要，所以软件架构必然不像修建架构一样，修建一经建成，批改的老本极高， 而软件应该走对应的方向，施展易于批改的特点。
“当初的大多数软件十分像埃及金字塔，在彼此之间堆建了成千上万的砖块，不足构造完整性，只是靠蛮力和成千上万的奴隶实现。”—— Alan Kay。
笔者认为，尽管这句话表白的意思我很同意，但实际上，金字塔作为帝王的陵墓，是有着残缺的设计逻辑，并且随着好几座金字塔的迭代的，以及逐步齐备的施工治理，前期金字塔是十分卓越的修建代表，并作为地球上最高的人造修建继续了好几千年。对于金字塔是否由奴隶建造还是存有争议。（图片来自 Isabella Jusková @ Unsplash）。
作为工程师，咱们一方面关注软件产品的能力和行为，这往往是一个我的项目的终点，另一方面咱们须要关注软件的架构设计，因为咱们心愿设计有着弹性、易于保护、高性能、高可用的零碎，更心愿零碎可能一直演进，而不是在将来被推倒重做。所以，回正咱们的视线，当咱们信心要设计一个好的架构时，咱们须要明确， 架构往往决定的是软件的非功能性需要 。这些非功能性需要有：
- 易于开发 ：咱们心愿工程师一进入团队就能够立即开始进行研发工作，咱们心愿代码易于浏览与了解，同时开发环境足够简略对立，说到这里大家能够回忆下当你进入我的项目时，学习上下文的苦楚。当咱们开始采纳 docker 辅助开发时，时任架构师提出了一个要求，只有一行命令就能够应用 docker 启动本地测试环境，而且必须所有的微服务都要做到这一点。苦楚的革新实现后，三年后进入我的项目的同学只须要装置好 docker，再在 ternimal 中运行一句 ./run-dev.sh 就可能获取一个具备残缺依赖的本地环境，提效显著。
- 不便部署 ：如果零碎的部署老本很高，那应用价值就不会很高了，咱们很多企业都存在那种动也不敢动，改也不敢改，停也不敢停的零碎，除了祷告它别挂掉如同没有别的方法，或者很多企业都采纳了 K8s 这种先进的编排零碎，然而在利用部署和上线时，还是走的每周四变更的路子。古代的公布形式 AB、金丝雀、灰度无奈采纳是因为革新老本过高，或者没有足够的自动化测试来保障改变平安，更别提将公布做到 CICD 外面了。
- 易于运维 ：DevOps 的初衷是建设一种缩短运维与研发间隔的文化，让呈现问题后更容易解决，心愿让大家将视线放在产品上而不是限定本人的工种，这并不是冀望运维的同学可能成为 Java 专家，迅速的进行 heap 剖析发现问题，咱们强调的是运维时的闭环能力。在软件产品层面，咱们也心愿产品是足够独立的、自治，能够独立部署，可能做到横向扩大，有着残缺的可观测性，毕竟当今的硬件老本很多时候是远远小于人力的。
- 保护老本 ：随着工夫的推移，给软件减少新性能就会变的越来越难，越是运行短暂的我的项目就会陷入重写还是重构的苦恼。往往危险在与，批改代码会减少毁坏已有性能的危险，而且技术债也会越来越多难以偿还，即便是重写某些性能和模块，咱们也很难确定是否真的笼罩到了所有的性能，简而言之，don’t break anything 确实很难做到。
- 以及最重要的一点， 演进能力 ：良好的架构设计应该能让零碎处于易于演进的状态，可能实现给飞驰的汽车换轮胎的能力，而不会被框架、底层的某种数据库、操作系统或者其余货色所绑架，然而这太难以做到了。确实，在我的项目进行技术选型时，因为某种数据库的个性而有偏向，然而在下层设计中，咱们必须保障不依赖于数据库的个性，而将应用这些个性的中央放到底层细节中。咱们也须要思考，不应用 Spring 提供的 Dependency Injection，咱们该如何组织咱们的 beans，也要思考未来零碎的前端是 web 还是 mobile 还是都要反对？
这里援用 Robert C·Martin（Uncle Bob）的原语，“软件产品是有两方面的价值，一方面是实现性能的价值，另一方面是架构的价值， 而架构的价值可能更重要一些，因为它代表着软件 soft 的个性。”
本书例子过少，而且不足现有风行框架的重构或者改良倡议，有点形而上，然而在方法论层面笔者还是认为值得一读。Robert C·Martin 对数据库（特指 RDBMS）的态度很值得探讨，首先他认为数据库是一种细节，在架构中应该与业务解耦，他强调业务代码与数据库的无关性。同时在咱们的代码进行计算时，表格往往不是现实的数据结构，比方有些场景会应用树、DAG 等等。能够回忆一下，当你须要把一个树存入数据库时，你该如何实现？
微服务是一种软件架构，不要扩大它
依据咱们之前的探讨，后端系统采纳微服务是不会影响到其性能上的价值，实质上微服务化和单体利用的差异并不会表白在性能上，很多微服务停顿不顺利的同学会常常说到：这货色用单体写早就完事儿！确实是这样， 这侧面也印证了微服务只是一种软件架构，而不是别的神奇的货色，并不是某个业务需要必须要应用微服务实现，咱们看中微服务，也是看中了架构方面的劣势，即那些非功能性需要 。也有人应用 pattern 来形容它，也有人说和 SOA 基本上是一个货色，只是粒度不同，所以咱们一开始就别置信这个世界有灵丹妙药，也别冀望有个什么技术可能霎时代替 Oracle。
作为开发“企业级后端利用”的同学，咱们常常会面临很多非业务需要上的苦恼：有时咱们须要同时反对挪动端、挪动 web、桌面端三种客户端；有时候咱们须要反对不同的协定比方 JSON 或 XML；有时咱们又须要应用不同的中间件传递音讯；或者在研发时，咱们晓得有一个中央写的不好，咱们想在将来补课重构；咱们想尝试最新的技术然而代价过高；零碎无奈扩容，或者老本极高；零碎过于简单无奈在本地运行导致极低的效率……这些苦恼才是采纳微服务的次要驱动力，回到咱们对软件架构的探讨之中，咱们心愿的是通过足够松耦合的独立服务，来升高组件之间变动的老本，也就是说明天更新发送告诉的性能，并不会影响到用户查看购物车，也不会让研发人员半天改完，再等三天能力上线。
然而世界上没有收费的午餐，尽管咱们晓得微服务有很多很好的个性，比方组件即服务、松耦合、独立部署、面向业务、高维护性、高扩展性等等，这里并不想展开讨论它的益处，咱们先思考投入老本。假如咱们每个同学都残缺的学习了微服务的所有常识，对市面上的框架、产品十分相熟，跃跃欲试筹备开始，在拆解完几个服务后，咱们会发现，没有足够的自动化伎俩，靠手动的形式进行测试、编译、部署、监控，这是不言而喻的会升高体验，如果没有优化好的部署策略，所有的服务都在某个公布日上线，那更是一种劫难。
随着规模的扩充，单体利用的代码改变老本会越来越大。很多时候咱们微服务的架构实际是存在误区的，咱们总认为流量通过某个 gateway 后中转某个服务，确漠视了服务之间调用的场景，现实的微服务架构应该是一张网，每个节点都是独立的、自治的服务。
一些之前应用单体很容易做到的场景，在分布式的环境下会更加艰难。比方咱们能够通过 RDBMS 提供的数据库事务来撑持一致性，然而如果订单服务和价格服务拆散，势必要进行分布式事务来保障一致性（往往是最终一致性），而分布式事务的老本和难度就不必赘述了。在单体环境下，咱们能够很轻松的应用切面进行权限验证，而在微服务的场景中，服务之间互相调用是难以管制的。
拆分服务或者服务边界划分是另一件很难做到的事件，最吃香的实践兴许是依据 DDD 去进行划分，人造的畛域或者子域（domain）貌似都能对应一个服务，因为足够的界线上下文（bounded context）可能放弃服务的独立性，使其细节被暗藏在界线之内，听起来是个不错的主见。然而事实却非常残暴，应用 DDD 生吞活剥去进行软件开发的例子不在少数，胜利例子也难以复制。
尽管我在实践中也常常应用业务畛域去进行服务划分，然而我并不认为这是 DDD 的做法，没有必要规定有多少个 domain 就有多少服务，也不须要规定 sub domain 是否独立服务。 与其进行顶层设计一揽子的解决方案，我更置信演进的力量，如果你真的须要拆分一个服务，足够的基础设施与自动化工具应该容许你低成本的去做，而不是一开始就画好所有的架构图 。这就跟所有的改革一样，革命派往往不是一步功成，而是逐步的积攒的。所以应用微服务，当你可能累赘的起（only you can afford it)，也示意你能累赘的失败一样，技术世界不存在欲速不达，all in 十分危险。
卫报网站（Guardian）的微服务革新就是一个很好的例子，网站外围仍旧是一个微小的单体，然而新性能通过微服务实现，这些微服务调用单体所提供的 API 来实现性能。对于经常呈现的市场流动（比方某个体育比赛的专用板块），这种形式可能疾速实现流动页面与性能，实现业务需要，并在流动完结后删除或抛弃。我之前参加我的项目中，也通过等量替换与重构，缓缓绞杀（Strangler Pattern）掉一个微小的古老的 JBoss 利用。
PlayStation 首席设计师 Mark Cerny 在往年的 PS5 新主机的技术分享中提到，游戏主机须要均衡好演进与反动（balance the evolution and revolution），咱们不想丢掉多年来开发者的积攒，在复用过来的成功经验时，咱们也心愿大家可能应用更先进的技术。
人人都爱恨 Spring Cloud
看起来，在 Java 世界中，Spring Cloud 貌似是微服务的最优解了，甚至在很多同学的简历上，Spring Cloud 简直能够和微服务划等号了，不止一次的有人通知我说：公司的技术栈不是 Java，所以搞不了微服务很好受，并不是我没有学习精力和冒险精力云云。很遗憾，对于软件架构来说，跟可没有规定编程语言，设计模式不是也出了很多版本吗？归根结底还是 Spring Cloud 的全家桶策略更吸引人，什么事儿都不如加上几个 jar 就能领有的神奇次时代架构更有吸引力。
不可否认，我在学习 Spring Cloud 的时候也惊叹其完整性，简直常见的微服务需要都有足够残缺的解决方案，而大多数计划是做在应用层，具备良好的适配性，比方 eurake 的注册发现、zuul 网关与路由、config service、hystrix circuit breaker 等等，通过对立的编程范式（基于 annotation 的注入与配置），足够丰盛的性能抉择（罕用性能甚至都有两种抉择），以及较好的集成形式。前有 Netflix 的胜利经验，后随着微服务的浪潮，再加上足够宏大的 Java 社区，能够说是王道中的王道。但并非 Spring Cloud 没有弱点，反倒这些功能设计与随后的容器化浪潮产生了一致，至今交融 Spring Cloud 与 Kubernetes 都是热门话题，这里咱们开展说说它的有余或者限度（limitation）。
侵入性与语言绑架
这可能是最大的问题，根本只能应用 Java 作为研发语言，这一点在国内也备受争议，因为不论是作为架构师还是入门的程序员，都须要尝试新的技术栈来进行储备或是采纳新的性能，而且比方应用自制的 client 去实现 ribbon 的负载平衡也是很难的，然而如果不必 Java，做到这一点也很难，不是说 Java 语言不够优良，而是咱们对将来应该有更多的抉择，对于一个技术公司来说编程语言应该不会成为限度，试问这个时代谁不想学习一点 golang 或者 rust 或者 scala 呢？其余服务比方 SSO、Config Service 也过于整体，如果想进行某项适配，则必须进行大量的批改（还好是开源的）。咱们很放心这种状况都会随着框架的老去而面临推到重来的境界，Ruby on Rails 可能就是前事不忘; 后事之师吧。侵入性是另一个问题，还记得咱们在探讨软件架构时所提倡的实际规定吗？尽量不要让顶层设计依赖底层的框架或者某种细节，然而满屏幕的 annotation 与 jar 的间接援用，无疑通知咱们想去掉它们还是十分难的。
云原生的交融问题
对于云原生，不论是 CNCF 还是 Pivotal（VMWare）都在强调容器化、微服务、面向云环境等，CNCF 围绕 Kubernetes 开始发展壮大，也随着这种先进的容器编排技术的风行人们慢慢发现它和 Spring Cloud 在性能上还是存在很多重叠，尽管 k8s 与 IaaS 没有重叠，然而当初还有多少厂商再推纯 IaaS 呢？既然有性能重叠，就有取舍，思考到 Spring Cloud 的全家桶属性，这个一致解决始终都不能很好的解决。
集中式的资源
不论是 Config、Eureka 都是聚合的单点，及时它们有集群的形式达到近乎 100% 的可靠性，但在逻辑架构上，所有的微服务都依赖它们，这些集中式的资源的耦合是十分强的，它们会始终存在在你的生产环境之中，直到最初一个应用它们的零碎下线。咱们在架构中须要防止应用共享的实例与资源，一个利用不会因为不能写日志而解体，也不应该因为本地没有 eureka 而无奈启动。
畏惧平台绑定
诚然，在过程之内解决服务注册发现、负载平衡是很好的，它代表了最好了平台无关性，但平台的其余能力也很难享受的到了。绑定 k8s 貌似是个更好的抉择，因为绝对于 Spring Cloud 它更灵便，也能做到不会被根底的云平台绑定，但也更难以把握与运维。当然我也不是认为 K8s 必须作为微服务的抉择，作为容器的编排平台，它能够做更多的事件（比方跑数据库、中间件等），运行微服务利用只是其中之一。
方法论的落地能力
2020 年曾经过了一半，从技术上来说，Serverless 曾经进入成熟期，Kubernetes 也更加成熟，曾经成为事实的规范。然而很多时候咱们的方法论与架构设计是跟不上的技术倒退的，很多同学可能还在经验每周的公布日，很多同学还没方法改良团队内老旧的技术，很多同学的 Jenkins 还是停留在打包的阶段，很多同学机器上还是没有装置 docker，很多时候并不是框架或者平台的问题，而是方法论还停留在过来。
放弃演进
应用程序也应该践行开闭准则，对扩大凋谢使得咱们在将来有更多的抉择。 微服务是一个很好的机会能让咱们真正的演进架构而不须要付出过多的代价，当咱们须要组件化零碎时，组件的要害个性正是可独立替换或降级，咱们能够不影响其余局部去进行替换和重构，这样的老本是显然低于摈弃旧的巨型框架而重写的 。有着正确的态度和工具，咱们能够更快、更频繁的管制变更，咱们能够激进的抉择新的技术栈，也能够合并两个耦合过紧的服务，随着服务的一直聚合、抽出，你会发现零碎的逻辑架构会越来越分明，再进行批改就会信心倍增了。咱们能够针对每个服务应用不同的存储技术，咱们能够应用 OSS 解决文件，而不是持续往 Oracle 外面塞图片和视频。
Istio 的解法与问题，以及 Mesh 还短少什么
这个揭幕雷击尽管槽点满满，但并没有升高社区对 Istio 的信念，反倒是慢慢发现这次的大改变使 Istio 变得有点好用了，能够在生产中采纳而不须要付出太多代价了。当然，漂亮话永远好说。
2017 年的时候 Service Mesh 还是一个襁褓中的概念，当初曾经成为了微服务畛域的将来之选，但遗憾的是目前只有 Istio 足够成熟能代表这项技术，当然我也有幸实际过相似的 Sidecar 来进行反向代理、日志收集、性能监控、健康检查等性能，然而间隔 Mesh 的愿景还是有大的差距。
明天并不想开展 Service Mesh 或者 Istio 的劣势，过程之外的解决方案可能确保零碎的灵活性，而流量管制、服务治理、端对端的传输平安、限流、发现注册等等， 咱们心愿工程师可能聚焦业务，实现架构的灵活性，聚焦真正的价值，而剩下的进行配置就好 。所以我想这也是 Serverless 被有限看好的起因，既然咱们想 delegate 对基础设施的管制，那为什么还须要关怀容器呢？Istio + k8s 的计划曾经足够好，至多咱们团队正在认真学习，在向客户提供最佳实际之前，咱们仍旧有很多问题须要解决，上面列出一些代表性的：
弹性与自复原问题
应用零碎度量、参数等触发弹性伸缩是常见的需要，这里咱们是应用云监控？还是本人搭一套？我始终偏向数据与用处解耦，应用 pub sub 模式解决问题，比方 CPU 过高可能会触发多个行为：触发警报，触发弹性规定，展现在 dashboard 上。咱们能够减少 pod 来分担服务的压力，或者因为某个 pod 异样退出后，启动新的 pod 来实现自复原，这系列动作也是须要咱们本人解决的。
监控与可观测性
日志、警报等可观测性的问题，这一方面的实际较多，惟一比拟放心的是 ARMS 或者 Newrelic 这种 APM 性能目前没在指标平台上实际过，咱们心愿可能清晰的看到每个服务的实时性能，目前这一部分还不足思考与设计。
限流与降级的实际
Istio 的流量控制能力是十分弱小的，如何对服务采取降级、限流这种常见的治理操作，也是须要总结出实践经验的。防止串流谬误（cascade failure）在微服务畛域也很常见，也须要防止故障蔓延。
多种自动化部署
蓝绿、灰度、金丝雀，这些多样的部署形式也须要落地，咱们可能会写一些 deployment util 之类的小脚本，部署的形式须要和 CICD 买通。一个部署工具，一个配置文件，一个 CICD 组成将来单个利用的部署形式。
ABAC 与 OPA
基于属性的权限管制以及 OPA 的可定制性咱们是十分看好的，而且 sidecar 能够在过程之外解决权限验证问题，确实值得尝试，刚好也学习下 golang 用于定制 OPA。
Saga 与弥补事件
分布式事务是微服务实际中的大坑，我已经也写过相似的文章，我的项目教训中更多的是将事务放在繁多的服务内，再加上我本人也没机会写过真正的网店零碎。弥补事件也是罕用的最终一致性计划，总之放在一起验证。
高可用和混沌工程
基于 K8s 实现利用的高可用应该不难，容器的天生劣势就是易于启动与治理，如果随机杀掉 pod 不会影响零碎可用性，这就算是实现了相似于 SLB + ECS + ASG 的能力，真正危险的是其余 非业务型 pod，比方 istio 的各种 supervisor。
实际微服务，作为架构师所思考的货色远远大于只是实现业务，然而一旦铺平道路，下来的研发与迭代将会更加顺利。
后记
如果你也对云原生架构有浓重的趣味，欢送 退出钉钉交换群 与咱们交换！
举荐下载
《深入浅出 Kubernetes》一书共会集 12 篇技术文章，帮忙你一次搞懂 6 个外围原理，吃透基础理论，一次学会 6 个典型问题的富丽操作！
< 关注阿里巴巴云原生公众号，回复 排查 即可下载电子书 >
参考资料
- https://martinfowler.com/articles/microservices.html
- https://medium.com/swlh/stop-you-dont-need-microservices-dc732d70b3e0
- https://medium.com/capital-one-tech/10-microservices-best-practices-for-the-optimal-architecture-design-capital-one-de16abf2a232
- https://www.geekgirlauthority.com/what-you-need-to-know-from-sonys-the-road-to-the-ps5/
- https://dev.to/bosepchuk/why-i-cant-recommend-clean-architecture-by-robert-c-martin-ofd
- https://istio.io/latest/blog/2020/tradewinds-2020/
- https://www.openpolicyagent.org/docs/latest/
作者简介
张羽辰（同昭） 阿里云交付专家，阿有着近十年研发教训，是一名软件工程师、架构师、咨询师，从 2016 年开始采纳容器化、微服务、Serverless 等技术进行云时代的利用开发。同时也关注在分布式应用中的平安治理问题，整顿《微服务平安手册》，对数据、利用、身份平安都有肯定得钻研。
“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术畛域、聚焦云原生风行技术趋势、云原生大规模的落地实际，做最懂云原生开发者的公众号。”