토크 소프트웨어 아키텍처 만 단어 : 비즈니스 아키텍처, 애플리케이션 아키텍처 및 클라우드 인프라

토크 소프트웨어 아키텍처 만 단어 : 비즈니스 아키텍처, 애플리케이션 아키텍처 및 클라우드 인프라

"에서이 부분 발췌 소프트웨어 아키텍처 설계 "

소프트웨어 개발은 ​​간단한 질문, 복잡한 솔루션에 대한 간단한 솔루션 시리즈의 다음 조합의 일련의 복잡한 문제이다. 소프트웨어 개발에서 가장 큰 도전은, 효율적으로 수요에 대한 변경을 할 수있게되고, 환경의 급격한 변화, 우리는 안정, 고 가용성 서비스를 계속 제공 할 수 있습니다. 소프트웨어 아키텍처는 골격 프레임 소프트웨어 시스템이다.

소위 아키텍처, 의견의 문제, 그것은 명확한 또는 정의 된 기준을 가지고 어려운 있지만, 우리는 인프라, 대형 항공 항공기 필요한 시스템이있는 아키텍처는 어려운 또는 지식인 아니라, 시스템 내부 전원 공급 등의 작은 기능 부품, 우리는 디자인해야 건축. 추상적 스키마는 시스템의 엔티티들 및 수행 된 엔터티와의 관계의 개요 설명이며, 할당은 오브젝트 / 기능 정보 요소 형태의 소자들 사이의 관계의 상황에 대응하도록 만들어진다 이것은 요소 사이 및 주변 환경의 변화와의 관계를 정의한다. 시스템 아키텍처는 원칙에 따라 세그먼트를 타겟팅 할 수 있습니다, 분할의 원칙이 병렬로 서로 다른 역할의 작업을 촉진하는 것입니다, 잘 구조화 된 창조적 인 활동이없는 창작 활동 구조보다 낫다.

소프트웨어 아키텍처의 핵심 가치, 즉 제어 시스템, 핵심 비즈니스 로직과 분리 디커플링의 기술적 인 세부 사항의 복잡성이다 . 소프트웨어 아키텍처에있어서,이 시스템을 구성하는 직접 추상화 컴포넌트를 설명하는 객체의 스케치이며, 다양한 구성 요소 사이의 연결 요소들 사이의 통신의 비교적 명백하고 상세한 설명이다. 구현 단계에서 이러한 추상적 인 구성 요소는 이러한 클래스 또는 특정 객체로, 실제 구성 요소에 정제된다. 객체 지향 영역에서, 구성 요소 사이의 연결은 일반적으로 인터페이스에 의해 달성된다. 할 수있는 시스템을, 책임 건축가는, 유용한 모델 검증을 만들고 수정하고 모델, 관리 구조를 확장하고, 합리적인 분해 추상화, 이해와 분석 요구 사항을 통해 자신의 마음을 훈련하고 시스템의 복잡성을 이해하기 위해 그것을 사용하려고 효과적인 착륙의 구현을 기술 규격을 개발하고 촉진 할 수있는 기술을 선택, 수정할 수, 전체 구조를 형성하기 위해 분해.

소프트웨어 아키텍처 카테고리

저자의 지식, 사실이 아키텍처는 사업 구조의 복잡성, 인프라하는를 해결하기 위해 분산 시스템의 존재에 초점을 맞춘 사업의 제어에 주로 초점을 맞춘, 비즈니스 아키텍처, 애플리케이션 아키텍처, 클라우드 인프라 이러한 범주로 구분됩니다 일련의 문제. 에 관계없이 건축 동시에, 우리는 보호 서비스 가용성의 변수 시스템을 달성하기 위해 희망하고있다. 또 다른 레벨은, 사업에 책임의 구분에 따라, 우리는 종종 건축가 소프트웨어 아키텍처 및 협회는 다음과 같은 범주로 나누어 져 있습니다 :

• 비즈니스 아키텍처 / 솔루션 아키텍처 : 핵심 사업은 시스템의 복잡성을 가지고 고객의 고통 점 / 비즈니스 측면을 이해하는 솔루션, 프로젝트, 기존 환경의 정의, 상위 요구 사항과 비 기능적 요구 사항, 문제 도메인의 분열과 건설 분야를 빗질 곰팡이 및 기타 작업, 통신 프로그램 추천 다수의 반복의 전체 아키텍처의 전달.

• 응용 프로그램 아키텍처 : 비즈니스 시나리오, 설계 응용 프로그램의 계층 구조, 응용 프로그램 사양의 개발, 정의 된 인터페이스와 데이터 교환 프로토콜의 필요에 따라. 그리고 응용 프로그램이 비 기능적 속성의 요구 사항 (성능, 보안, 안정성을 충족하는지 확인, 동시에 가용성과 시스템의 유지 보수를 보장하기 위해, 빠른 사업 개발을 지원하기 위해 수용 가능한 수준에서 응용 프로그램의 복잡성을 제어하려고 등).

• 데이터 아키텍처 : 데이터 자산을 유지하기 위해 효과적이고 쉽게 형성하기 위해 데이터 세트, 통합 데이터 정의 사양, 표준화 된 데이터 표현을 구축에 초점을 맞 춥니 다. 데이터 시각화 플랫폼 사업자, 플랫폼 데이터 공유, 데이터 권한 관리 플랫폼을 포함하여, 통합 빅 데이터 처리 플랫폼을 만듭니다.

• 미들웨어 아키텍처 : 건축가는 CAP 사이에 상충 관계가있는 동안 미들웨어 시스템을 구축에 초점, 서버 부하를 해결하기 위해 분산 서비스 등록 및 검색, 메시징 시스템, 캐싱 시스템, 분산 데이터베이스 및 기타 문제가 필요합니다.

• 운영 및 유지 보수 아키텍처 : 운영 및 시스템 계획, 선택, 온라인 배포의 유지 보수에 대한 책임, 표준화 된 운영 및 유지 보수 시스템의 구축.

• 물리적 인프라 : 물리적 인프라의 관심은 인프라에 설정 엔진 룸, 네트워크 토폴로지, 네트워크 탭, 프록시 서버, 웹 서버, 응용 프로그램을 포함한 일부 소프트웨어 및 하드웨어 시스템, 심지어 클라우드 플랫폼을 중심으로, 하드웨어 구성 요소에 소프트웨어를 넣어하는 방법이다 서버, 보고서 서버, 서버, 스토리지 서버 및 호스트 통합.

건축 패턴과 건축 양식

중앙 문제는 소프트웨어 아키텍처 설계 아키텍처는 소프트웨어 재사용의 수준을 달성 할 수있는 아키텍처 패턴을 중복 여부입니다. 즉, 여부를 다른 소프트웨어 시스템에서, 동일한 아키텍처를 사용하여. 우리는 소프트웨어 아키텍처, 소프트웨어 아키텍처 모델 자주 언급 (건축 패턴) 및 소프트웨어 아키텍처 스타일 (건축 스타일)에 대해 이야기합니다.

소프트웨어 아키텍처 모델은 종종 특히 중복 아키텍처의 특정 문제를 해결하는 데 사용하고, 건축 양식라는 특정 아키텍처 설계를위한 것입니다. 소프트웨어 아키텍처 스타일은 시스템의 조직의 분야에서 특정 응용 프로그램의 일반적인 패턴에서 설명, 건축 양식 효과적으로 전체 시스템에 다양한 모듈 및 서브 시스템을 구성하는 방법에 대한 구조와 분야에서 많은 시스템에 공통적 인 특성의 의미 및 지침을 반영한다.

기사, 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 기사와 코드 인덱스 매트릭스 와 같은 프로젝트의 소스 코드로 더 자세한 문서 디렉토리 탐색 정보보기를. "마지막으로, 당신은 마이크로 채널 대중 번호에 대해 우려 할 수 있습니다 도로 기술의 곰 최신 정보".