认识达内从这里开始

在说到提高团队的业务能力的时候，我们除了需要掌握关于敏捷开发的技术以外，提高微交互设计能力也是非常有用的。下面，我们就一起来了解一下，在提高团队微交互能力上都有哪些方法。

持续交付

对于微服务的成功实施，团队持续交付能力是至关重要的衡量指标。在由上百个服务组成的复杂系统中，如果所有服务都按照人为指定发布周期进行整体交付，很容易出现由于细小的失误导致大面积线上故障。

持续交付实践要求每个独立服务都具有完备的交付流水线，在流水线的末端随时能提供当时最新的可工作、可交付的产品。持续交付通常会配合自动化的测试和部署手段，从而减少功能代码提交到上线的端到端时间。这就使得每个独立服务能按照各自不同的节奏进行发布，并且将自己的发布状态可视化出来。

全功能团队

全功能团队是DevOps运动所倡导的一种产品团队组织结构，通过将不同角色的业务和技术成员纳入到团队，组成具备端到端交付和运营能力的完整单元。

康威定律阐述了开发团队的组织结构和其设计的产品结构之间具有的相似关系。许多的实践结果也表明，将全功能团队实践应用在微服务产品中带来的收益，要远远超过它在传统模块化开发的产品中所带来的收益。这是因为微服务的架构中的所有服务真正具备独立运行和独立运营的能力，从本质上来说就是一个端到端的子业务产品。

自动化运维

自动化运维是实施持续交付的必要前提，因此也可以说是采用微服务架构的必要前提。但这里所说的自动化运维，不仅仅包含持续交付所需的服务部署时『一键操作』能力，更重要的是运维基础设施构建的自动化、以及服务灾备、恢复的自动化。微服务架构最初受到追捧的一个原因是它灵活的『局部Scale Out』能力，以功能点为单元的扩展、收缩，这对于具有业务周期性的服务而言更加重要。

服务高可用

由于微服务系统中存在着众多跨服务调用，任何一个服务都不能假设自己可以随意的停机一段时间而不对系统的整体功能造成影响。但在现实情况中，正常的服务升级或意外的故障都有可能造成服务短暂或长时间的中断，这种中断轻则引起局部功能不可用，重则导致连锁反应造成重大事故。这些都是在架构设计时候就应该予以考虑的问题。应对这两类情况的方法分别是对服务采用高可用的部署方式，和进行不离线的部署。实现服务高可用的方法有很多，常见的有：L7负载均衡、DNS负载均衡、服务发现、同步/异步消息队列等。

不离线部署

不离线部署是确保服务随时能发布的必要措施，也是微服务架构团队需要关注的一种能力。在实际应用中，除了一些天生支持不离线部署的技术栈，如Erlang，多数的服务是原生不支持热升级的。对于这些服务，通常来说可根据服务『是否能递进式升级』和『是否具有长任务』的特性，分成三种类型：『不能递进升级的服务』，『能递进升级、无长任务的服务』，以及『能递进升级、有长任务的服务』，分别采用不同策略进行。这里先介绍一下服务的『递进式升级』和『具有长任务』。

监控告警

内存不足、磁盘耗尽、网络中断、服务失效，这些天灾人祸随时可能殃及产品的服务集群。很难想象，在一个庞大的微服务系统中，如果没有合适的监控和告警设施，服务的运营会变得多么混乱不堪。

容器化

容器是一种能够加速促进团队DevOps水平的虚拟化技术。它通过把服务和系统依赖全量打包的镜像格式，将运行环境的设计提前到了开发阶段，并且实现了开发、测试、线上环境的高度一致。由于容器屏蔽了不同服务运行时的差异性，使得基于这种方式进行服务的大规模部署和调度变得简单。具体来说体现在以下几个方面：首先是运行环境的隔离。在虚拟机时代，由于每个业务依赖的系统环境不同，服务器之间无法通用。

作者：林帆

来源公众号：Docker

【免责声明】：本内容转载于网络，转载目的在于传递最新信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。