微服务和微服务架构
了解微服务的优缺点以及它们与单体式的区别。
不久前，构建软件应用的首选方法还是采用单体式架构，这是一种独立的的自主单元。对许多开发人员来说，此方案一开始效果确实不错，但当应用的复杂性上升后便不太灵光了。如果要对单体式系统中的一小部分代码进行修改，那就需要重建整个系统，对整个系统运行测试，并且要部署该应用的全新版本。
后来，微服务诞生了。此方案可将软件系统分解成更小的单元，让其自主开发并执行部署。微服务架构经 DevOps 运动推行，力求实现持续频繁交付各类更新，如新功能、缺陷修复和安全性改进等。在许多情况下，微服务也成为企业使用现代编程语言和更新技术堆栈来重写传统应用的一个途径。
微服务是用于持续交付和部署大型复杂应用的小型单元的集合。
什么是微服务？
微服务架构也可简称为“微服务”。作为一种应用构建方法，它可将应用构建为一系列可独立部署、去中心化且能自主开发的服务。这些服务采用松散耦合，可独立部署且易于维护。单体式应用是作为单个不可分单元来构建的，而微服务则将该单元分解为一系列独立单元，从而为更大的整体做贡献。微服务是持续交付实践的基础，能让团队快速适应用户需求，因此是 DevOps 不可或缺的一部分。
一个微服务就是一个负责某段域逻辑的 Web 服务。多个微服务结合起来形成一个应用，各自为网域提供一部分功能。微服务使用 API（如 REST 或 gRPC）彼此交互，但不了解其他服务的内部工作。微服务之间的这种和谐交互就是一种微服务架构。
借助微服务架构，开发人员可以组建小规模团队，使用不同的堆栈和解耦部署来专门开发不同的服务。例如，Jira 由多个微服务提供支持，每个微服务都提供特定的功能，包括搜索事务、查看事务详情、评论和事务转换等。
微服务的特征
微服务架构没有正式的定义，但有一些常见模式或特征需要了解。
自治组件
微服务架构的基本构造块是组件，它可以是由软件、Web 服务/资源或应用构成的软件包，也可以是包含一系列相关功能的模块。或者，简单来说，就是 Martin Fowler 所表示的：“软件组件是指可以独立更换和升级的部件。”
在微服务架构中，每个组件都可以独立开发、部署、运营、变更和重新部署，而不影响其他服务的功能或应用的完整性。
组件可与其他组件搭配使用，以提供客户体验或业务价值。最常见的组件是服务和库，但也可将 CLI 工具、移动应用、前端模块、数据管道、机器学习模型以及许多其他可在微服务架构中应用的概念封装其中。
清爽的界面
单个组件建立完成后，需要大量逻辑才能通过 RPC、REST over HTTP 或基于事件的系统等通信机制实现彼此之间的通信。这些机制可以采用同步或异步的方法，而微服务可以将这两种方法结合使用。
最重要的，每个微服务都应该提供一个简单、直观的协定，其中描述使用者可以如何使用该服务。一般来说，协定将通过与该服务一起发布的 API 来完成。
谁构建，谁运行
DevOps 的理念是“谁构建，谁运行”，强调若不考虑团队构成，则无法将架构转变为微服务。以构建高质量软件为共同目标，DevOps 将不同职能角色（开发、QA、发布工程、运营）的激励措施重新整合到一个团队。诸如 CI/CD、自动化测试和功能标记之类的 DevOps 实践可加快部署速度，并有助于维护系统的稳定性和安全性。另外，每个团队都可构建和部署自己负责的微服务，而不影响其他团队。
云的发展简化了微服务的构建、部署和运营。持续集成、持续交付和自动化测试等基础架构自动化技术可以为团队提供帮助。
面向服务的体系结构与微服务
面向服务的体系结构 (SOA) 和微服务是 Web 服务架构的两种类型。与微服务一样，SOA 包含可重复使用、彼此独立工作的专用组件。两种架构类型之间的区别在于服务类型的繁琐分类。
SOA 有四种基本服务类型：
- Business
- Enterprise
- 应用程序
- 基础架构服务
这些类型定义了底层服务特定于域的相关责任。相比之下，微服务只有两种服务类型：功能和基础架构。
这两种架构在企业的不同层面上共享同一套标准。微服务架构的存在归功于 SOA 模式的成功。因此，微服务架构模式是 SOA 的一个子集。此处的关键在于每个服务的运行时自主性。
微服务的优势
灵活
小型独立团队通常会在微服务内构建服务，因此鼓励团队采用敏捷实践。团队可以独立工作和快速行动，从而缩短开发周期。
灵活扩展
微服务特意设计为分布式并可在集群中部署，因此可以跨服务边界进行动态水平扩展。如果某一微服务达到负载容限，可将该服务的新实例快速部署到相关集群，以帮助缓解压力。
频繁发布
微服务的主要优势之一是发布周期频繁且速度更快。作为持续集成和持续交付 (CI/CD) 的关键要素，微服务允许团队试验新的功能，并在出现状况时回滚。这样，代码更新变得更加轻松，新功能的面市时间也得以加快。
技术灵活性
微服务架构不一定要遵循采用某一工具链的固定方法，而是允许团队自由选择想要使用的工具。
注重质量
将业务关注点分割为独立的微服务，意味着负责该服务的服务团队可将重点放在已完成的高质量交付成果上。
高可靠性
通过划分功能，微服务可降低发布更新时破坏整个应用或代码库的风险。隔离和修复各项服务中的错误和漏洞也变得轻松简单。您可以仅针对特定服务部署变更，而不必关闭整个应用，因而提供了更高的可靠性。
微服务的挑战
开发蔓延
从单体式架构向微服务迁移意味着复杂性加剧。多个团队会在更多的地方创建更多的服务。确定不同组件之间的关系、特定组件的负责人，以及如何避免对依赖组件造成负面影响，这些都可能变得非常棘手。这种开发蔓延若得不到管理，就会导致开发速度减慢和运营绩效降低。随着系统不断发展，必须要有一支经验丰富的运营团队来管理不断的重新部署和架构中的频繁变更。
缺少明确的责任
微服务架构增添了由谁负责什么的困惑。DevOps 团队可以运行 API、组件库、监控工具和 Docker 镜像的组合，以便用户部署应用。深入了解组件的相关信息非常重要，其中包括组件的负责人、资源以及与其他组件之间不断演变的关系。众多团队之间需要精准沟通和协调，以便参与其中的每个人都能轻松找到了解某个产品所需的知识。
基础架构成本呈指数级增长
添加至生产部署中的每项新微服务都有自己的成本，例如在测试套件、部署手册、托管基础架构和监控工具等方面。
组织开销增加
需要更高层面的沟通和协作来协调微服务架构团队之间的更新和对接。
调试
调试包含多个微服务（各自都有自己的日志集）的应用可能具有挑战性。单个业务流程可能会在不同的时间跨多台计算机运行，从而进一步加大调试难度。
事件响应
掌握微服务事件响应情报非常重要，包括诸如谁在使用微服务、微服务被部署到何处、微服务的部署方式，以及在出现问题时与谁联系等信息。
微服务和 DevOps：步调一致
鉴于微服务的复杂性和依赖性不断增加，DevOps 在部署、监控和生命周期自动化方面的实践被视为微服务架构不可或缺的一部分。正因为此，微服务通常被认为是实施 DevOps 文化的第一步，它可以实现：
- 自动化
- 更好的可扩展性
- 可管理性
- 灵活
- 更快的交付和部署
微服务架构的关键技术和工具
容器、Docker 和 Kubernetes
容器仅仅是应用及其所有依赖关系的打包，以便其能够轻松、一致地进行部署。容器没有自身操作系统的开销，因此比传统虚拟机更小巧、更轻盈。它们可以更快运行和停止，非常适合存在于微服务架构中的小型服务。
随着服务和容器的激增，编排和管理大型容器群组变得至关重要。Docker 是一种广受欢迎的容器化平台和运行时环境，可以帮助开发人员构建、部署和运行容器。但是，仅凭借 Docker 实现大规模运行和管理容器并非易事。Kubernetes 以及 Docker Swarm、Mesos 和 HashiCorp Nomad 等其他解决方案有助于解决大规模容器化问题。
容器化和容器部署是分布式基础架构的一种新模式。Docker 和 Kubernetes 将服务打包到一个可以快速部署和丢弃的完整容器中。这些基础架构工具为微服务架构提供了补充。微服务可以使用容器管理系统进行容器化，以及轻松地部署和管理。
API 网关
微服务架构中的各项服务通过定义明确的 API 相互通信。API 网关充当反向代理，接受 API 调用、收集完成调用的服务者，并返回结果。API 网关提供服务于单个 API 端点的抽象，即使 API 由多个微服务提供服务。API 网关还可以整合速率限制、监控、授权、身份验证以及路由到相应微服务等事务。
消息传递和事件流传输
由于微服务的分布式性质，团队需要一种方法来共享状态变更和其他事件。消息传递系统在微服务之间进行通信，从而允许某些微服务将事件作为其主接口的一部分进行处理。例如，对 Confluence 页面的变更会生成一个事件，触发搜索的重新索引并向关注该页面的用户发送通知。
日志记录和监控
微服务很难跨越多个服务识别和解决事务。拥有相应的观察工具来记录、监控和跟踪非常重要。这有助于了解微服务的行为方式，识别潜在的问题，对问题进行故障排除，以及调试故障。
持续集成/持续交付
微服务的主要优势之一是发布周期频繁且速度更快。作为 CI/CD 的关键要素，微服务允许团队试验新的功能，并在出现状况时回滚。这样，代码更新变得更加轻松，新功能的面市时间也得以加快。
开发人员门户
随着分布式架构复杂性加剧，开发团队可以从相应工具获益，这种工具可将有关工程输出和团队协作的信息整合到一处。例如，Atlassian Compass 就是专门设计用来提供数据和洞察信息的。这些数据和洞察信息跨多个 DevOps 工具链，从而帮助遏制微服务蔓延。
微服务的未来
容器化和容器部署已成为分布式基础架构的一种常见模式。Docker 和 Kubernetes 一类的工具可将服务打包到一个可以快速部署和丢弃的完整容器中。这些新型基础架构工具为微服务架构提供了补充，因为微服务可以使用容器管理系统进行容器化，并且轻松地部署和管理。
实施微服务应被视为一个长期过程，而不是团队的近期目标。
从小处着手，了解分布式系统的技术要求，并逐一扩展组件。然后，随着经验和知识的积累，逐步提取更多服务。
借助 Compass 浏览微服务
使用微服务架构时，Atlassian Compass 可管理扩展的分布式架构的复杂性。它是一个可扩展的开发人员体验平台，可将有关工程产出及团队协作的分散信息整合到一个集中且可搜索的位置。除通过组件目录帮助您控制微服务蔓延之外，Compass 还可帮助您制定最佳实践并使用记分卡来衡量软件的运行状况。此外，您也可借助在 Atlassian Forge 平台上构建的扩展功能，获得整个 DevOps 工具链的数据和洞察信息。
