トークソフトウェアアーキテクチャ万語：ビジネス・アーキテクチャ、アプリケーションアーキテクチャとクラウドインフラストラクチャ

トークソフトウェアアーキテクチャ万語：ビジネス・アーキテクチャ、アプリケーションアーキテクチャとクラウドインフラストラクチャ

「からこの部分の抜粋ソフトウェアアーキテクチャの設計」

ソフトウェア開発は、単純な一連の質問、複雑なソリューションへのシンプルなソリューションのシリーズの組み合わせの中に複雑な問題になります。ソフトウェア開発における最大の課題は、効率的な需要のために変更を加えることができることが、環境の急速な変化は、我々は安定した、高可用性サービスを提供し続けることができます。ソフトウェアアーキテクチャは、スケルトンフレーム・ソフトウェア・システムです。

いわゆるアーキテクチャ、意見の問題、クリアまたは定義された基準を持っていることは困難である。しかし、アーキテクチャは、とらえどころのか高尚ではない、我々はインフラ、大型民間航空機、システム内部の電源供給と小さいの機能部品を必要とするシステムがあり、我々は、設計する必要がありますそして、アーキテクチャ。抽象、スキーマはシステム内のエンティティと行うエンティティ間の関係の抽象記述は、割り当ては、オブジェクト/機能及び情報要素の形態、要素間の関係との間の状況に対応させますこれは、要素間および周囲の環境の変化との関係を定義します。システムアーキテクチャは、原理に従ってセグメントをターゲットにすることができ、分割の原理は適切に構成創作活動がない創作活動構造よりも優れている、並列に異なる役割の作業を容易にすることです。

ソフトウェアアーキテクチャのコア値は、その制御システム、コアビジネスロジックと分離とデカップリングの技術的な詳細の複雑さです。システムのソフトウェアアーキテクチャは、システムを構成するオブジェクトを直接抽象成分で説明し、スケッチであり、様々な構成要素間の接続は、コンポーネント間の通信の比較的明確かつ詳細な説明です。実施段階では、これらの抽象的な構成要素は、クラスまたは特定のオブジェクトとして、実際の部品に洗練されています。オブジェクト指向の領域で、コンポーネント間の接続は、一般的にインターフェースすることによって達成されます。責任の建築家は、彼の心を訓練し、有用なモデルを作成するには、合理的な分解と抽象化、理解と解析要件を通じて、システムの複雑さを理解するためにそれを使用して、検証、モデルを洗練して展開する経営体制をしようとしている;ことができるシステム全体的なアーキテクチャを形成するために分解し、技術仕様を開発し、効果的な着陸の実施を促進することができ、技術選択を修正することができます。

ソフトウェアアーキテクチャカテゴリ

著者の知識では、実際には、アーキテクチャは、主に事業構造の複雑さ、インフラ、解決するために、分散システムの存在に焦点を当てたのビジネスの制御に焦点を当て、ビジネスアーキテクチャ、アプリケーションアーキテクチャ、クラウドインフラストラクチャこれらのカテゴリに分類され一連の問題。同時に、アーキテクチャに関係なく、私たちは、保護サービスの可用性の変数システムを実現するために期待しています。別のレベルは、ビジネスでの役割分担に応じて、我々は多くの場合、建築家のソフトウェアアーキテクチャ、および関連は、次のカテゴリに分類されることができます。

• ビジネスアーキテクチャ/ソリューション・アーキテクチャ：コアビジネスは、システムの複雑さをもたらすための解決策であるが、顧客の痛点/ビジネス面、プロジェクトの定義、既存の環境を理解し、上位要件と非機能要件、問題領域の部門と建設の分野をコーミング金型や他の作業、通信、プログラムの推奨、反復の数、全体的なアーキテクチャの配達。

• アプリケーションアーキテクチャ：ビジネスシナリオ、設計アプリケーションの階層、アプリケーション仕様の開発、定義されたインタフェースとデータ交換プロトコルのニーズに応じて。そして、迅速な事業展開をサポートするために、同時にシステムの可用性と保守性を確保するために、アプリケーションが非機能的属性（パフォーマンス、セキュリティ、安定性の要件を満たしていることを確認し、許容可能なレベルでのアプリケーションの複雑さを制御しようなど）。

• データアーキテクチャ：データ資産を維持するのに有効かつ簡単に形成するために、データ・セット、統一されたデータ定義の仕様、標準化されたデータ表現を、構築に焦点を当てます。データ可視化プラットフォーム事業者、プラットフォームのデータ共有、データの著作権管理プラットフォームを含め、統一されたビッグデータ処理プラットフォームを作成します。

• ミドルウェアアーキテクチャ：ミドルウェアのシステムを構築する上での焦点は、建築家は、CAPの間のトレードオフである一方で、サービス登録と発見、メッセージングシステム、キャッシュ・システム、分散データベースやその他の問題を配布し、サーバーの負荷を対処する必要があります。

• 運用・保守アーキテクチャ：システムの企画、選択、上のラインの展開、標準化された運用・保守体制の確立の運用および保守を担当します。

• 物理的なインフラ：物理インフラの懸念は、インフラストラクチャ・ソフトウェアとハ​​ードウェア・システム、およびセットアップエンジンルーム、ネットワークトポロジ、ネットワークタップ、プロキシサーバ、Webサーバ、アプリケーションを含むでもクラウドプラットフォームのいくつかの並べ替えに焦点を当て、ハードウェアコンポーネント上でソフトウェアを配置する方法ですサーバー、レポートサーバー、サーバー、ストレージサーバやホストを統合します。

建築パターンや建築様式

中心的な問題は、ソフトウェアアーキテクチャの設計は、アーキテクチャは、ソフトウェアの再利用のレベルを達成することができ、アーキテクチャパターンを複製するかどうかです。換言すれば、異なるかどうかをソフトウェアシステムに、同じアーキテクチャを使用。我々は、ソフトウェアアーキテクチャ、ソフトウェアアーキテクチャモデルしばしば言及（建築パターン）とソフトウェアアーキテクチャスタイル（建築スタイル）について話すとき。

ソフトウェアアーキテクチャモデルは、多くの場合、具体的重複アーキテクチャの特定の問題に対処するために使用され、建築様式は、指定された特定のアーキテクチャ設計のためのものです。ソフトウェアアーキテクチャスタイルはシステムの組織の分野における特定のアプリケーションの通常のパターンで説明されています。建築様式は、構造と意味論分野で多くのシステムに共通する特徴の、かつ効果的に完全なシステムの中に様々なモジュールやサブシステムを整理する方法についてのガイダンスを反映しています。

記事の著者のシリーズでは、CRUD、階層化アーキテクチャ、六角形のアーキテクチャ、オニオンアーキテクチャ、RESTとDDDは、建築様式を考えている、とCQRS、EDA、UDLAは、サービスがマイクロアーキテクチャモデルに分けました。

ソースの複雑さに対処するためのシステム

ソフトウェア開発では、プログラマは、しばしば、最も創造的な活動の一つである架空の世界を、作成するために、現実の束縛から支配することができます。プログラミングは唯一のソフトウェア開発プロセスの上限が作成されている私たちのオブジェクトを理解することであることを意味し、思考と創造的思考組織能力を必要とされます。ソフトウェアの進化によって、より多くの機能のポイントを追加し、システムが複雑になる：様々なモジュール（モジュール）との間で様々な微妙な依存関係があります。システムの複雑さは、あなたがシステムを変更すると、すべての関連要因を総合的考慮に入れてすることはますます困難になる、プログラマのため、時間をかけて蓄積されます。これは、オープン進行が遅くなるソフトウェア、およびさらに、開発の進行を遅らせる開発コストの増加につながっバグの導入を、になるだろう。システムの任意のライフサイクルでは、複雑さが必然的に増加します;管理システムの複雑さの作業システム、より多くの人々を開発する必要性が大きいほど、より困難。

ドメイン駆動設計の本Tucaoいわゆるスパゲッティアーキテクチャ上のエリック・エヴァンスは、それは本当に便利な事をしたコードですが、それは、それが実行される方法を説明するのは難しい、彼はこのジレンマのための主な理由はそれであると考えています、複雑さの複雑さと問題領域の技術的な詳細は、最終的には全体の複雑さに指数関数的な成長につながる、一緒に混合されます。

複雑さは、私たちの主観的な意志にない傾向がある複雑化を意味し、非常に多くの場合、意図的ではない、薄い空気から出てくるではありません。部屋の中の象のように、私たちは見て見ぬふりをすることができない、逃れることはできません。ソースの複雑さは次のようになります。

• 降着と継続的な反復：インクリメンタルデザインは、ソフトウェア設計を決して終わることのない手段は、デザインは、プログラマは常に設計の問題を考慮する必要があり、システムのライフサイクルで発生し続けます。インクリメンタル開発も継続的再構成を意味します。システムの初期設計は、ほぼ最善の解決策になることはありません。経験で、あなたは確かに優れたデザインを見つけるでしょう。

• 交互且无扩展性设计：当吸积效应导致的大规模系统，结合了交互这个特性，会使技术系统更加复杂。一个技术系统除了作用于自身，还会与其它大量系统产生交互。比如下单购买一件商品，那么订单系统，商品系统，支付系统，物流系统，卡券系统就会交互协作。这样吸积的复杂性，由于交互特性的出现，会呈现几何级数上升。

• 不合理的业务封装：不合理的业务封装是一个相对宽泛的概念，其具体的表现譬如面向过程而不是对象、分层不合理等。

• 缺乏统一语言：典型的敏捷开发的结构，流水线上的各个角色往往会专注于自己负责的环节，精细化的分工也限制了每个角色的全局视角；虽然我们经常提倡所谓的主人翁意识，但是在落地时又很难去推进。

• 缺乏约束与规范：在团队协作开发的背景下，缺少规范和约束会严重损害架构的一致性（Consistency），代码的可维护性将急剧下降。可能规范在实现层面就是命名、分包等不影响代码运行的小问题，但是千里之堤，溃于蚁穴，正是这些微末的不注意导致了整体复杂性的雪崩。

复杂性的应对永远不会是一劳永逸，我们需要不断地推陈出新，是动态、渐进的重塑自己对软件系统的认识，不断认识问题和寻找更优解的持续迭代。第一个控制复杂性的途径是代码简单，意图清晰（Obvious）。例如: 减少特殊场景的处理，或变量命名一致性都能降低系统复杂性。另一种方式就是对复杂问题的抽象然后分而治之。

领域驱动设计

本部分节选自《领域驱动设计》

DDD 领域驱动设计，起源于 2004 年著名建模专家 Eric Evans 发表的他最具影响力的著名书籍：《Domain-Driven Design – Tackling Complexity in the Heart of Software》，Eric Evans 在该书中只是提供了一套原始理论，并没有提供一套方法论，因此多年来对于 DDD 也是见仁见智。更早些时候 MartinFowler 曾经提出贫血模型与充血模型的概念，他认为我们大多数系统以 POJO 作为模型，只有普通的 getter、setter 方法，没有真正的行为，好像缺少血液的人，在 Evans 看来，DDD 中模型都是以充血形式存在，也就是说在 DDD 中，我们设计的模型不仅包含描述业务属性，还要包含能够描述动作的方法，不同的是，领域中一些概念不能用在模型对象，如仓储、工厂、服务等，如强加于模型中，将破坏模型的定义。

领域驱动设计的战略核心即是将问题域与应用架构相剥离，将业务语义显现化，把原先晦涩难懂的业务算法逻辑，通过领域对象（Domain Object），统一语言（Ubiquitous Language）转化为领域概念清晰的显性化表达出来。

• 统一语言，软件的开发人员/使用人员都使用同一套语言，即对某个概念，名词的认知是统一的，建立清晰的业务模型，形成统一的业务语义。将模型作为语言的支柱。确保团队在内部的所有交流中，代码中，画图，写东西，特别是讲话的时候都要使用这种语言。例如账号，转账，透支策略，这些都是非常重要的领域概念，如果这些命名都和我们日常讨论以及 PRD 中的描述保持一致，将会极大提升代码的可读性，减少认知成本。。比如不再会有人在会议中对“工单”、“审核单”、“表单”而反复确认含义了，DDD 的模型建立不会被 DB 所绑架。

• 面向领域，业务语义显性化，以领域去思考问题，而不是模块。将隐式的业务逻辑从一推 if-else 里面抽取出来，用通用语言去命名、去写代码、去扩展，让其变成显示概念；很多重要的业务概念，按照事务脚本的写法，其含义完全淹没在代码逻辑中没有突显出来。

• 职责划分，根据实际业务合理划分模型，模型之间依赖结构和边界更加清晰，避免了混乱的依赖关系，进而增加可读性、可维护性；单一职责，模型只关注自身的本职工作，避免“越权”而导致混乱的调用关系。通过建模，更好的表达现实世界中的复杂业务，随着时间的发展，不断增加系统对实际业务的沉淀，也将更好的通过清晰的代码描述业务逻辑，模型的内聚增加了系统的高度模块化，提升代码的可重用性，对比传统三层模式中，很有可能大量重复的功能散落在各个 Service 内部。

微服务与云原生架构

本部分节选自《微服务与云原生》

单体分层架构

在 Web 应用程序发展的早期，大部分工程是将所有的服务端功能模块打包到单个巨石型（Monolith）应用中，譬如很多企业的 Java 应用程序打包为 war 包，最终会形成如下的架构：

巨石型应用易于搭建开发环境、易于测试、易于部署；其缺陷也非常明显，无法进行局部改动与部署，编译时间过长，回归测试周期过长，开发效率降低等。集中式架构分为标准的三层：数据访问层、服务层和 Web 层。

在 Web2.0 时代刚刚流行的时候，互联网应用与企业级应用并没有本质的区别，集中式架构分为标准的三层：数据访问层、服务层和 Web 层。

• 数据访问层用于定义数据访问接口，实现对真实数据库的访问；
• 服务层用于对应用业务逻辑进行处理；
• Web 层用于处理异常、逻辑跳转控制、页面渲染模板等。

SOA 面向服务架构

SOA（Service-Oriented Architecture） 面向服务架构，是在互联网应用规模迅速增长，集中式架构已无法做到无限制地提升系统的吞吐量的背景下，产生的涉及模块化开发、分布式扩展部署等相对宽泛的概念。

SOA 是一个组件模型，它将应用程序的不同功能单元（称为服务）通过这些服务之间定义良好的接口和契约联系起来。SOA 中的接口独立于实现服务的硬件平台、操作系统和编程语言，采用中立的方式进行定义。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是 SOA 的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。

实施 SOA 的关键目标是实现企业 IT 资产的最大化作用。要实现这一目标，就要在实施 SOA 的过程中牢记以下特征：可从企业外部访问、随时可用、粗粒度的服务接口分级、松散耦合、可重用的服务、服务接口设计管理、标准化的服务接口、支持各种消息模式、精确定义的服务契约。

服务消费者（Service Consumer）可以通过发送消息来调用服务，这些消息由一个服务总线（Service Bus）转换后发送给适当的服务实现。这种服务架构可以提供一个业务规则引（Business Rules Engine），该引擎容许业务规则被合并在一个服务里或多个服务里。这种架构也提供了一个服务管理基础（Service Management Infrastructure），用来管理服务，类似审核，列表（billing），日志等功能。此外，该架构给企业提供了灵活的业务流程，更好地处理控制请求（Regulatory Requirement），例如 Sarbanes Oxley（SOX），并且可以在不影响其他服务的情况下更改某项服务。

由于分布式系统十分复杂，因此产生了大量的用于简化分布式系统开发的分布式中间件和分布式数据库，服务化的架构设计理念也被越来越多的公司所认同。如下是 Dubbo 官方文档公布了一张有关 SOA 系统演化过程的图片：

MSA 微服务架构

微服务（Microservices Architecture Pattern）由 Martin Fowler 在 2014 年提出的，是希望将某个单一的单体应用，转化为多个可以独立运行、独立开发、独立部署、独立维护的服务或者应用的聚合，从而满足业务快速变化及分布式多团队并行开发的需求。如康威定律（Conway’s Law）所言，任何组织在设计一套系统（广义概念）时，所交付的设计方案在结构上都与该组织的通信结构保持一致，微服务与微前端不仅仅是技术架构的变化，还包含了组织方式、沟通方式的变化。

对于微服务，不同背景的人也有不同的见解，对于熟悉 SOA 的开发者，微服务也可以认为是去除了 ESB 的 SOA 的一种实现方案；ESB 是 SOA 架构中的中心总线，设计图形应该是星形的，而微服务是去中心化的分布式软件架构。SOA 更多强调重用，而微服务偏向于重写。SOA 偏向水平服务，微服务偏向垂直服务；SOA 偏向自上而下的设计，微服务偏向自下而上的设计。

微服务与微前端原理和软件工程，面向对象设计中的原理同样相通，都是遵循单一职责(Single Responsibility)、关注分离(Separation of Concerns)、模块化(Modularity)与分而治之(Divide & Conquer)等基本的原则。从巨石型应用到微服务的衍化也并非一蹴而就，如下图也演示了简单的渐进式替代过程：

Cloud Native 云原生架构

云原生是通过构建团队、文化和技术，利用自动化和架构来管理系统的复杂性和解放生产力。
— Joe Beda，Heotio CTO，联合创始人

Pivotal 是云原生应用的提出者，并推出了 Pivotal Cloud Foundry 云原生应用平台和 Spring 开源 Java 开发框架，成为云原生应用架构中先驱者和探路者。早在 2015 年 Pivotal 公司的 Matt Stine 写了一本叫做迁移到云原生应用架构的小册子，其中探讨了云原生应用架构的几个主要特征：符合 12 Factors 应用、面向微服务架构、自服务敏捷架构、基于 API 的协作以及抗脆弱性。2015 年 Google 主导成立了云原生计算基金会（CNCF），起初 CNCF 对云原生（Cloud Native）的定义包含以下三个方面：应用容器化、面向微服务架构、应用支持容器的编排调度。

云原生应用程序简单地定义为从头开始为云计算架构而构建应用程序；这意味着，如果我们将应用程序设计为预期将部署在分布式、可扩展的基础架构上，我们的应用程序就是云原生的。随着公共云将承载越来越多的算力，未来云计算将是主流的 IT 能力交付方式，CNCF 也对云原生进行了重新定义：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用；云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

• Codeless 对应的是服务开发，实现了源代码托管，你只需要关注你的代码实现，而不需要关心你的代码在哪，因为在整个开发过程中你都不会感受到代码库和代码分支的存在。

• Applicationless 对应的是服务发布，在服务化框架下，你的服务发布不再需要申请应用，也不需要关注你的应用在哪。

• Serverless 对应的则是服务运维，有了 Serverless 化能力，你不再需要关注你的机器资源，Servlerless 会帮你搞定机器资源的弹性扩缩容

这些技术组合搭配，能够构建容错性好、易于管理和便于观察的松耦合系统；再结合可靠的自动化手段，云原生技术能够使工程师轻松地对系统作出频繁和可预测的重大变更。由此可见，云原生是保障系统能力灵动性地有效抓手；云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。微服务架构非常适合云原生应用程序；但是，云原生同样存在着一定的限制，如果你的云原生应用程序部署在 AWS 等公有云上，则云原生 API 不是跨云平台的。

云原生应用的关键属性包括了：使用轻量级的容器打包、使用最合适的语言和框架开发、以松耦合的微服务方式设计、以 API 为中心的交互和协作、无状态和有状态服务在架构上界限清晰、不依赖于底层操作系统和服务器、部署在自服务、弹性的云基础设施上、通过敏捷的 DevOps 流程管理、自动化能力、通过定义和策略驱动的资源分配。云原生是分布式应用当下重要的发展路径，其终态应当是 Distributionless，所有与分布式相关的问题由云平台解，分布式应用的开发会跟传统应用的开发一样方便，甚至更加便捷。

云基础架构

本部分节选自《分布式基础架构之虚拟化与编排》

虚拟机

虚拟机由某些特定的硬件和内核虚拟化组成，运行客户操作系统。称为管理程序的软件创建虚拟化硬件，其可以包括虚拟磁盘，虚拟网络接口，虚拟 CPU 等。虚拟机还包括可以与此虚拟硬件通信的宾客内核。管理程序可以托管，这意味着它是一些在主机操作系统（MacOS）上运行的软件，如示例中所示。它也可以是裸机，直接在机器硬件上运行（替换你的操作系统）。无论哪种方式，管理程序方法都被认为是重量级的，因为它需要虚拟化多个部分（如果不是全部硬件和内核）。

VM 需要硬件虚拟化才能实现机器级隔离，而容器则只需要在同一操作系统内进行隔离操作。 随着隔离空间数量的增加，开销差异变得非常明显。

容器

在过去几年里，云平台发展迅速，但其中困扰运维工程师最多的，是需要为各种迥异的开发语言安装相应的运行时环境。虽然自动化运维工具可以降低环境搭建的复杂度，但仍然不能从根本上解决环境的问题。

Docker 的出现成为了软件开发行业新的分水岭，容器技术的成熟也标志着技术新纪元的开启。Docker 提供了让开发工程师可以将应用和依赖封装到一个可移植的容器中的能力，这项举措使得 Docker 大有席卷整个软件行业并且进而改变行业游戏规则的趋势，这像极了当年智能手机刚出现时的场景——改变了整个手机行业的游戏规则。Docker 通过集装箱式的封装方式，让开发工程师和运维工程师都能够以 Docker 所提供的镜像分发的标准化方式发布应用，使得异构语言不再是捆绑团队的枷锁。

容器是包含应用程序代码，配置和依赖关系的软件包，可提供运营效率和生产力。容器为我们提供了可预测的，可重复的和不可变的运行预期，容器的兴起是 DevOps 即服务的一个巨大推动因素，可以克服当今面临的最大安全障碍。容器化通过在操作系统级别进行虚拟化来使应用程序可移植，从而创建基于内核的隔离的封装系统。容器化的应用程序可以放在任何地方，无需依赖项运行或需要整个 VM，从而消除了依赖关系。

作为独立的单元，容器能够在任何主机操作系统，CentOS，Ubuntu，MacOS，甚至是像 Windows 这样的非 UNIX 系统中运行。容器还充当标准化的工作或计算单元。一个常见的范例是每个容器运行单个 Web 服务器，数据库的单个分片或单个 Spark 工作程序等，只需要扩展容器的数量就能够便捷地扩展应用。每个容器都有一个固定的资源配置（CPU，RAM，线程数等），并且扩展应用程序需要只扩展容器的数量而不是单个资源原语。当应用程序需要按比例放大或缩小时，这为工程师提供了更容易的抽象。容器也是实现微服务架构的一个很好的工具，每个微服务只是一组协作容器。例如，可以使用单个主容器和多个从容器来实现 Redis 微服务。

Kubernetes 与编排

随着虚拟化技术的成熟和分布式架构的普及，用来部署、管理和运行应用的云平台被越来越多地提及。IaaS、PaaS 和 SaaS 是云计算的三种基本服务类型，分别表示关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务，以及关注业务应用的软件即服务。容器的出现，使原有的基于虚拟机的云主机应用，彻底转变为更加灵活和轻量的容器与编排调度的云平台应用。

然而容器单元越来越散落使得管理成本逐渐上升，大家对容器编排工具的需求前所未有的强烈，Kubernetes、Mesos、Swarm 等为云原生应用提供了强有力的编排和调度能力，它们是云平台上的分布式操作系统。容器编排是通常可以部署多个容器以通过自动化实现应用程序的过程。像 Kubernetes 和 Docker Swarm 这样的容器管理和容器编排引擎，使用户能够指导容器部署并自动执行更新，运行状况监视和故障转移过程。

Kubernetes 是目前世界范围内关注度最高的开源项目，它是一个出色的容器编排系统，用于提供一站式服务。Kubernetes 出身于互联网行业巨头 Google，它借鉴了由上百位工程师花费十多年时间打造的 Borg 系统的理念，安装极其简易，网络层对接方式十分灵活。Kubernetes 和 Mesos 的出色表现给行业中各类工程师的工作模式带来了颠覆性的改变。他们再也不用关注每一台服务器，当服务器出现问题时，只要将其换掉即可。业务开发工程师不必再过分关注非功能需求，只需专注自己的业务领域即可。而中间件开发工程师则需要开发出健壮的云原生中间件，用来连接业务应用与云平台。

Kubernetes、Service Mesh 和 Serverless 三者共同演绎不同层次的封装和向上屏蔽下面的细节。Kubernetes 引入了不同的设计模式，实现对各种云资源全新、有效和优雅的抽象和管理模式，让集群的管理和应用发布变成了件相当轻松且不易出错的事。被广泛采用的微服务软件架构将分布式应用的各种复杂度迁移到了服务之间，如何通过全局一致、体系化、规范化和无侵入的手段进行治理就变成了微服务软件架构下至关重要的内容。Kubernetes 细化的应用程序的分解粒度，同时将服务发现、配置管理、负载均衡和健康检查等作为基础设施的功能，简化了应用程序的开发。而 Kubernetes 这种声明式配置尤其适合 CI/CD 流程，况且现在还有如 Helm、Draft、Spinnaker、Skaffold 等开源工具可以帮助我们发布 Kuberentes 应用。

Service Mesh 通过将各服务所共用和与环境相关的内容剥离到部署于每个服务边上的 Sidecar 进程而轻松地做到了。这一剥离动作使得服务与平台能充分解耦而方便各自演进与发展，也使得服务变轻而有助于改善服务启停的及时性。Service Mesh 因为将那些服务治理相关的逻辑剥离到了 Sidecar 中且作为独立进程，所以 Sidecar 所实现的功能天然地支持多语言，为上面的服务采用多语言开发创造了更为有利的条件。通过 Service Mesh 对整个网络的服务流量进行技术收口，让异地多活这样涉及流量调度的系统工程实现起来更加优雅、简洁与有效，也能更加方便地实现服务版本升级时的灰度、回滚而改善安全生产质量。由于技术收口，给服务流量的治理和演进、排错、日志采集的经济性等疑难问题创造了新的发展空间。

延伸阅读

您可以通过以下导航来在 Gitbook 中阅读笔者的系列文章，涵盖了技术资料归纳、编程语言与理论、Web 与大前端、服务端开发与基础架构、云计算与大数据、数据科学与人工智能、产品设计等多个领域：

• 知识体系：《Awesome Lists | CS 资料集锦》、《Awesome CheatSheets | 速学速查手册》、《Awesome Interviews | 求职面试必备》、《Awesome RoadMaps | 程序员进阶指南》、《Awesome MindMaps | 知识脉络思维脑图》、《Awesome-CS-Books | 开源书籍（.pdf）汇总》

• 编程语言：《编程语言理论》、《Java 实战》、《JavaScript 实战》、《Go 实战》、《Python 实战》、《Rust 实战》

• 软件工程、模式与架构：《编程范式与设计模式》、《数据结构与算法》、《软件架构设计》、《整洁与重构》、《研发方式与工具》

• Web 与大前端：《现代 Web 开发基础与工程实践》、《数据可视化》、《iOS》、《Android》、《混合开发与跨端应用》

• 服务端开发实践与工程架构：《服务端基础》、《微服务与云原生》、《测试与高可用保障》、《DevOps》、《Node》、《Spring》、《信息安全与***测试》

• 分布式基础架构：《分布式系统》、《分布式计算》、《数据库》、《网络》、《虚拟化与编排》、《云计算与大数据》、《Linux 与操作系统》

• データ科学、人工知能と深い学習：「数理統計」、「データ分析」、「機械学習」、「深い学習」、「自然言語処理」、「ツールおよびエンジニアリング」、「産業用アプリケーション」

• 製品のデザインとユーザー体験：「製品設計」、「インタラクティブな体験」、「プロジェクト管理」

• 産業応用：「業界の神話」、「ドメイン」、「電子商取引」、「知的生産」

また、あなたも訪問することができxCompassをか、対話形式で、検索の記事は/リンク/書籍/コースを必要と見つけるMATRIXの記事とコードインデックス行列のようなプロジェクトでは、ソースコードとして表示より詳細な記事のディレクトリナビゲーション情報。「：最後に、あなたはまた、マイクロチャネル公共数を心配することができ、道路技術のクマ最新情報については、」。