微服务开发的进阶之路
在微服务开发领域,我们已经掌握了诸多核心技能,但这仅仅是开始。还有许多值得深入探索的主题,能帮助我们进一步提升服务的性能、可靠性和可维护性。
自动化工具
自动化在微服务开发和运维中起着至关重要的作用。以下是一些常用的自动化工具:
- Terraform :用于自动化创建基于云的资源。通过编写配置文件,Terraform 可以帮助我们快速、一致地创建和管理云基础设施。例如,我们可以使用 Terraform 配置文件来创建 AWS 上的 EC2 实例、S3 存储桶等资源。
- Ansible、Chef 和 Puppet :这些配置管理工具允许我们在实例内部进行配置,如复制文件、更改文件内容、安装软件包等。以 Ansible 为例,我们可以编写 playbook 来定义一系列的任务,然后在多个服务器上执行这些任务,实现自动化配置。
- HashiCorp Packer :可用于构建自定义的操作系统镜像。我们可以使用 Packer 结合上述配置管理工具,为不同的云平台(如 AWS、GCP、VMware 或 Docker)创建操作系统镜像。
以下是这些工具的相关链接:
| 工具名称 | 链接 |
| ---- | ---- |
| Terraform | https://www.terraform.io/ |
| Ansible | https://www.ansible.com/ |
| Chef | https://www.chef.io/ |
| Puppet | https://puppet.com/ |
使用自动化工具不仅可以提高开发和运维效率,还能在发生灾难时快速恢复整个应用套件,避免数周的繁琐工作。但在使用时,要注意避免创建新的单体架构,应遵循特权分离和易于维护的原则,将功能拆分为更小的项目。
应用扩展
当应用需要处理更多工作时,有两种常见的扩展方式:
- 垂直扩展 :传统的做法是在更大的计算机上运行应用,增加内存、CPU 核心和磁盘空间。但这种方式并不能提高应用的可靠性,且当应用规模足够大时,可能没有足够大的计算机来运行。
- 水平扩展 :使用多个较小的计算机来处理工作。在基于容器的服务部署中,我们可以通过增加 Docker swarm 的实例数量来实现水平扩展。不过,应用需要有可复制和可扩展的状态管理机制,以确保客户端会话、购物车内容等信息在不同页面之间保持一致。
微服务架构使得应用扩展更加容易,但要注意每个组件之间的通信,一个区域的负载增加可能会影响其他区域。通过仔细监控系统,可以发现整体系统的瓶颈,从而优先处理最需要优化的区域。
内容分发网络(CDNs)
我们的应用所提供的一些内容(如 HTML 页面、JavaScript、图像和视频流)通常不经常变化。内容分发网络(CDNs)旨在提供全球分布式的静态内容。它们可以作为应用的前置层或与应用并行工作,比定制服务更快地向客户端提供可缓存的内容。
部分 CDNs 还支持根据客户端及其网络质量动态缩放图像和视频,或提供针对分布式拒绝服务(DDoS)攻击的保护,是任何基于 Web 的服务的宝贵工具。
多云部署
在评估运行服务的风险时,我们会发现组织可能完全依赖于一个云提供商。为了提高冗余性,常见的做法是将服务部署到多个云提供商(如 Azure、GCP、Amazon 等),并分散工作负载。
然而,不同的云提供商具有不同的功能集、安全要求,且无法共享存储和密钥管理,这会带来很多复杂性。虽然 Terraform 可以在一定程度上帮助解决这个问题,但通常更可行的做法是在同一提供商的多个区域进行部署。如果确实需要多个云提供商,应根据组件之间的交互方式进行分离。这与将单体架构拆分为微服务的策略类似,成功的迁移需要不同组件之间有清晰的接口,以及对关注点和需求进行良好的隔离。
Lambda 函数
Lambda 或云函数是一种无服务器部署方式,适用于小型、短期的任务,能够快速扩展和收缩。虽然在 2021 年异步框架在这方面的支持有限,但它们在同步代码中被广泛使用,其响应能力由同时运行的函数数量控制。
mermaid 流程图:
graph LR
A[应用扩展需求] --> B{扩展方式}
B --> C[垂直扩展]
B --> D[水平扩展]
D --> E[微服务架构]
E --> F[监控系统]
F --> G[发现瓶颈]
G --> H[优先处理]
通过以上介绍,我们可以看到在微服务开发中还有许多技术和策略值得我们去探索和应用。合理运用这些技术,可以帮助我们构建更加高效、可靠的微服务应用。
微服务开发的进阶之路
扩展监控
监控和收集指标可以记录应用程序的运行情况,测量数据能从计数、大小或时间流逝等方面呈现部分信息。为获取更多信息,我们可以使用日志服务记录应用程序产生的消息。
在 Linux 服务器中,日志通常通过 rsyslog 传递并存储在 /var/log 目录下的文件中。但在云服务尤其是容器环境中,本地日志的作用有限,因为我们需要调查所有运行的容器和云实例才能了解情况。因此,使用集中式日志服务更为合适。
可以使用 AWS CloudWatch、Google 的 Cloud Logging 等工具,也可以运行 Splunk 或 Logstash 等服务。Logstash 是流行的开源 ELK 栈的一部分,该栈包含 Elasticsearch、Logstash 和 Kibana,可用于收集、搜索和可视化日志数据。
使用结构化日志技术,我们可以轻松为所有日志条目添加注释,确定是哪个微服务生成的日志,从而更好地关联事件。集中式日志服务能帮助我们将一个组件中的错误与其他区域的报告联系起来。同时,每个微服务的隔离性意味着它们对其他组件的影响应通过设计好的接口实现,而不是由于同一服务器或进程树中的资源限制产生的副作用。
以下是一些相关工具的链接:
| 工具名称 | 链接 |
| ---- | ---- |
| ELK 栈 | 相关参考链接 |
| AWS CloudWatch | 对应官方链接 |
| Google 的 Cloud Logging | 对应官方链接 |
| Splunk | 对应官方链接 |
| Logstash | 对应官方链接 |
履行承诺
在编写软件时,我们通常是为了帮助公司或开源项目实现目标,而不仅仅是个人行为。仅依靠直觉判断工作是否出色往往会产生误导,因为人类的直觉会受到各种偏见的影响。因此,我们必须进行测量,收集数据、观察模式并分析数据。
为了向自己和他人展示软件的运行情况,我们可以从三个层面进行思考:
1. 服务级别指标(SLIs) :这是我们可以测量的一系列指标。开发者容易想到与技术相关的 SLIs,例如:
- API 响应时间(以毫秒为单位)
- 不同 HTTP 状态码的计数
- 每个请求传输的字节数
同时,也应包含组织层面的指标,例如:
- 在线商店结账流程所需的时间
- 结账过程中放弃购买的潜在客户数量
- 运行服务的财务成本,特别是自动扩展的服务
2. 服务级别目标(SLO) :在 SLI 的基础上设置阈值或警报值。例如:
- 少于 1% 的 HTTP 状态码表示服务器错误
- 完成结账操作的比率必须超过 75%
- 用户至少 99.9% 的请求能够成功完成而无错误
3. 服务级别协议(SLAs) :当 SLO 未达到时,SLAs 规定了服务提供商和用户之间应采取的措施。例如:
- 服务级别指标 :记录的 HTTP 500 错误数量
- 服务级别目标 :HTTP 500 错误不应超过总请求的 1%
- 服务级别协议 :通知站点可靠性工程师并告知受影响的客户
创建 SLO 有助于开发者和产品团队成员理解应用的重要方面,并向所有相关人员证明应用正在按预期运行。
总结
作为软件开发人员,我们需要不断提升技能和知识,尝试新技术和架构,并在他人的工作基础上进行构建。我们的核心技能是以理性和系统的方式处理问题,将问题的每个部分分解为可管理的小块,并确保自己和相关人员能够理解整个过程。
微服务方法在系统设计中运用了相同的技术,使每个组件更易于理解和调查。与许多方法一样,只有经过深思熟虑地应用,而不是盲目跟风,才能发挥出良好的效果。
设计优秀的应用需要知识、技能和经验的结合。通过合理运用自动化、扩展策略、监控手段以及履行承诺等技术和方法,我们可以构建出更加高效、可靠的微服务应用,为业务目标的实现提供有力支持。
mermaid 流程图:
graph LR
A[编写软件] --> B[测量数据]
B --> C{评估层面}
C --> D[SLIs]
C --> E[SLOs]
C --> F[SLAs]
D --> G[技术指标]
D --> H[组织指标]
E --> I[设置阈值]
F --> J[未达目标处理]
超级会员免费看

被折叠的 条评论
为什么被折叠?



