微服务迁移前,来听听这6个思考和经验

dataman 发表了文章 • 0 个评论 • 118 次浏览 • 2018-01-30 10:15 • 来自相关话题

 
 
 小数近期为大家推送了不少微服务方面的文章,之前的一份微服务调研报告《微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑》受到广泛关注。今天推送的这篇技术文章,与您再来深入探讨下企业为什么要寻求微服务,会遇到哪些问题,做好哪些准备。


今天,对软件的需求变化比以往任何时候都快。这就要求有一个合适的架构来实现灵活的变更。然而,考虑到Web应用的角度,灵活性往往受到阻碍。随着时间的推移,各种意想不到的依赖关系会使架构看起来像一个大泥球(Big Ball of Mud,BBoM)。


类似BBoM的庞大单体架构显示出的复杂性急剧增加。这需要各个团队之间的协调努力,才不会导致生产力降低。作为对策,企业引入了Scrum敏捷方法来优化他们的软件工程流程。但是,经常缺乏技术自主权。




1、敏捷性和微服务

在敏捷软件开发中,一个理想的架构足够灵活,可以处理快速调整的需求。遵循敏捷宣言的原则,最好的架构以功能需求驱动的方式出现。但架构也需要前期设计的努力,以实现预期的灵活性。由于需求的不确定性,严格的瀑布式的前期大型设计(Big Design Upfront ,BDUF)被忽略了。BDUF不适合大量连贯工作量的敏捷思想,也称为the batch size。


微服务方法限制了batch size,因为每一个微服务只涵盖整个应用的一部分。所有部分共同涵盖不同的业务功能,例如在电商应用中显示产品的详细信息。重要的一点是,单一业务能力的责任转移到一个需要跨职能一致和需要DevOps文化的团队。


因此,微服务是一个模块化的概念,可以解释技术层面和组织层面。这个想法是围绕清晰分离的业务能力建模一个架构,每个业务能力都是作为一个微服务实现的。通过实施自己的架构与系统的其他部分分离,允许建立大规模的软件增量与小型和独立的团队。微服务最适宜的企业是,旨在缩短业务上线时间,但无法应对当前架构和组织结构快速变化需求的那些企业。


向微服务迁移有许多挑战。以下提供了从BBoM引入微服务的几点指南。



2、微服务迁移的六大影响因素

向微服务的迁移可以完全脱离,也依赖于单体(因素1)。关键的决定是,目标架构的微服务是否包含自己的前端(frontend)(因素2)。在这个阶段,技术和组织方面之间的相互作用已经变得明确。当涉及从巨石中分离出第一个微服务时,应该确保底层的新模型不会被旧的破坏(因素3)。运维中的迁移应该考虑风险,并采取适当的措施(因素4)。通过自动化过程来支持(因素5)。把适当的工作放在优先位置。所需的透明度通过敏捷的组织文化来建立。将敏捷转换与微服务迁移结合起来会带来额外的挑战(因素6)。


1改变
人们经常认为,完全重写应用程序是充满风险的。但是这个应用程序的发布并不是以一个Big Bang的方式来完成的。相反,可以选择渐进的方法。但是,巨石应用和微服务一起构成应用程序的“微服务 – 单体 - 混合”架构往往是不可避免的。特别是如果有竞争的压力,新的特性必须不断传递给客户,那么混合是唯一的解决方案。迁移是一个长期的过程,可以持续2年以上。


为了缩短应用程序处于混合状态的时间,建议将迁移视为变化的机会。在这种情况下,改变意味着实施新的要求,而且接受现有功能的遗漏。一方面,考虑迁移的应用程序是旧的应用程序的准确副本,减少迁移工作是明智的。另一方面,提供不适用于旧技术堆栈的新功能增强利益相关方的信任。这种迁移可以视为进步而并非停滞。


2系统分解有两个必须考虑的决定。
首先,是否通过使用现有的代码库或者完全重写功能来提取微服务。
其次,定义目标架构,并且必须做出决定,微服务是自带前端,还是多个微服务集成在一个UI单体中。

当使用现有的代码库时,该代码库的副本就是跳板。那么给定的部分已经表现出高度的自主性。而且,当项目范围局限于较少人数开发应用时,这种方法可能会取得成功。当挑战是将多个团队分离时,建议将微服务定义为自己的前端。


这需要进一步讨论如何解释微服务的层次。关于三层架构,可以区分两种微服务类型。一方面是只包含数据和应用程序层的微服务(图1)。另一方面还有从数据层到表现层的微服务。


当使用“2层微服务”时,在建立前端的这种多微服务时建立了一个UI单体。这带来了将微服务整合到同一个前端的耦合团队的风险。相比之下,提供自己的前端部分的“全栈微服务”(例如UI碎片)则为团队提供了更高程度的自主权(图2)。


3模型边界保护作为一个起点,建议从中等复杂度的单个上下文开始。这样做的时候,保护即将实现这个上下文的微服务底层模型很重要。因此,应该规定一条规则,即禁止通过数据层访问(如JDBC或直接API调用)从整体数据访问数据。相反,数据应该从后台异步传输到后台的微服务,同时还要在新旧模式之间进行转换。这可以看作两个数据存储的同步,并符合构建防腐层(ACL)的思想,这是一个域驱动设计(DDD)的概念。在这种情况下,ACL可以作为微服务和巨石的模型完整性保护器(图3)。

风险监测任何迁移都有风险。特别是在进行完全重写时,如果新应用程序与现有应用程序相比得到相同的结果,则应使用与业务相关的度量标准(如营业额)进行衡量。然后,通过逐渐将新应用交付给越来越多的客户,控制经济风险。在这一点上,应该考虑诸如Canary Releasing的部署策略。


另外,建议在生产环境中测试微服务,然后再将其推广给客户。这可以通过向微服务提供请求并完全观察他们的行为Shadow Traffic来实现。性能问题可以在不影响应用程序的情况下展开,因为各自的响应被省略。这种做法是由两位专家和文献描述的。


其他措施也可以支持降低云服务迁移过程中的风险。使用诸如特性切换之类的机制在旧的和新的实现之间切换。它们提供了灵活性,仅通过更改配置来控制这一点,而无需重新部署整个应用程序。


5自动化和测试为了减少TTM(上市时间),作为微服务的部署流水线,建议将价值流建模和自动化。在这里,要考虑从代码提交到部署构建的每一步。这确保部署可以经常进行。此外,这从一开始就支持高度的测试覆盖,因为测试也是该流水线的一部分。


在考虑自动化测试时,专家会参考所谓的自动化测试金字塔。测试金字塔由三个测试层组成:单元,服务和UI测试。每层测试的数量减少,导致金字塔形状--许多单元测试和少量UI测试。为了确保多个微服务如预期的那样相互整合,依靠UI测试是合理的。但UI测试对于开发和维护来说是脆弱和昂贵的。这就是为什么在没有UI的情况下单独进行测试非常重要:使用模拟对象自主地测试微服务。借助模拟对象,可以模拟与其他微服务或巨石应用的交互。相应的测试被称为,自动测试金字塔内的服务级别测试。


6敏捷转型引入敏捷方法并立即迁移到微服务是巨大的变化。因此,建议将其分成几个步骤,并寻求逐渐改变。否则动机和定向障碍的风险太高。通过引入Scrum这样的敏捷方法,理想的微服务出现,是随着时间的推移争取团队的自主性。

尽管Scrum主要是在一个跨职能和以产品为中心的团队中解决软件开发过程,大规模的组织也需要采用。Scrum没有提供解决多个敏捷团队协调的解决方案。还有一些坚定的观点认为,对于大型项目来说,应该避免使用灵活的方法来分割产品。随着时间的推移,出现了不同的Scrum和敏捷方法扩展方法。例如,LeSS(大规模Scrum),Nexus和SAFe(缩放敏捷框架)是根据其市场份额为大型组织提供敏捷性的相关方法。


在更大的组织环境中建立敏捷方法时,建议先从一个团队开始,然后再增加越来越多的团队。同样在LeSS中,这被描述为耗时,但却是以功能为中心的团队,同时打破功能孤岛的安全方式。




透明度

此外建议记录产生的非功能性工作,例如在积压工作中实施ACL,并合理安排其他要求。在SAFe中,引入了可以代表上述技术和机制的实施以及迁移工作的推动者的故事。它们确保了透明度,展现了业务与IT之间潜在的相互依赖关系。因此,应根据2位专家的建议,与企业和技术负责人进行优先排序。

图4:敏捷和微服务之路



3、总结

微服务包含组织层面和技术方面。这就是为什么引入微服务涉及两种情况下的措施。如果没有单体考虑,微服务的好处是脆弱的。从纯粹的技术角度来看,微服务可以使用瀑布式软件工程方法来实现。但是,为了充分发挥每个微服务的自主性,它们被嵌入到敏捷文化中。


特别是,拥有多个团队的组织可以从微服务的非技术方面获益。从数据层向前端分解一个系统,将团队分离开来。因此,如果多个团队使用一个前端开发应用程序,那么团队边界在架构中反映最好。这些团队可以自主地加速应用程序的部分。在单体应用程序和分层的团队中,这是更困难的。在这里,复杂的依赖需要协调跨越团队边界的活动。因此TTM下降。


由于敏捷团队由开发人员和非技术人员组成,因此IT和业务需要携手合作。微服务的出现是由于敏捷团队争取自主权。当团队决定转向微服务时,迁移本身没有任何价值,可以向客户交付新功能。尽管如此,微服务迁移工作仍需要优先考虑。这需要透明度。只有不断提高透明度,敏捷性和微服务才能彼此加速。否则,长期不会降低TTM的风险很高。


为了避免在引入微服务时构建未来的传统软件,建立敏捷思维和不断重新思考解决方案很重要。


原文链接:
6 Things to Consider for Microservice Migration

  查看全部

v2-342dd117dd4cd06bde68a2b67dc3857e_hd.jpg

 
 
 小数近期为大家推送了不少微服务方面的文章,之前的一份微服务调研报告《微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑》受到广泛关注。今天推送的这篇技术文章,与您再来深入探讨下企业为什么要寻求微服务,会遇到哪些问题,做好哪些准备。


今天,对软件的需求变化比以往任何时候都快。这就要求有一个合适的架构来实现灵活的变更。然而,考虑到Web应用的角度,灵活性往往受到阻碍。随着时间的推移,各种意想不到的依赖关系会使架构看起来像一个大泥球(Big Ball of Mud,BBoM)。


类似BBoM的庞大单体架构显示出的复杂性急剧增加。这需要各个团队之间的协调努力,才不会导致生产力降低。作为对策,企业引入了Scrum敏捷方法来优化他们的软件工程流程。但是,经常缺乏技术自主权。




1、敏捷性和微服务

在敏捷软件开发中,一个理想的架构足够灵活,可以处理快速调整的需求。遵循敏捷宣言的原则,最好的架构以功能需求驱动的方式出现。但架构也需要前期设计的努力,以实现预期的灵活性。由于需求的不确定性,严格的瀑布式的前期大型设计(Big Design Upfront ,BDUF)被忽略了。BDUF不适合大量连贯工作量的敏捷思想,也称为the batch size。


微服务方法限制了batch size,因为每一个微服务只涵盖整个应用的一部分。所有部分共同涵盖不同的业务功能,例如在电商应用中显示产品的详细信息。重要的一点是,单一业务能力的责任转移到一个需要跨职能一致和需要DevOps文化的团队。


因此,微服务是一个模块化的概念,可以解释技术层面和组织层面。这个想法是围绕清晰分离的业务能力建模一个架构,每个业务能力都是作为一个微服务实现的。通过实施自己的架构与系统的其他部分分离,允许建立大规模的软件增量与小型和独立的团队。微服务最适宜的企业是,旨在缩短业务上线时间,但无法应对当前架构和组织结构快速变化需求的那些企业。


向微服务迁移有许多挑战。以下提供了从BBoM引入微服务的几点指南。



2、微服务迁移的六大影响因素

向微服务的迁移可以完全脱离,也依赖于单体(因素1)。关键的决定是,目标架构的微服务是否包含自己的前端(frontend)(因素2)。在这个阶段,技术和组织方面之间的相互作用已经变得明确。当涉及从巨石中分离出第一个微服务时,应该确保底层的新模型不会被旧的破坏(因素3)。运维中的迁移应该考虑风险,并采取适当的措施(因素4)。通过自动化过程来支持(因素5)。把适当的工作放在优先位置。所需的透明度通过敏捷的组织文化来建立。将敏捷转换与微服务迁移结合起来会带来额外的挑战(因素6)。


1改变
人们经常认为,完全重写应用程序是充满风险的。但是这个应用程序的发布并不是以一个Big Bang的方式来完成的。相反,可以选择渐进的方法。但是,巨石应用和微服务一起构成应用程序的“微服务 – 单体 - 混合”架构往往是不可避免的。特别是如果有竞争的压力,新的特性必须不断传递给客户,那么混合是唯一的解决方案。迁移是一个长期的过程,可以持续2年以上。


为了缩短应用程序处于混合状态的时间,建议将迁移视为变化的机会。在这种情况下,改变意味着实施新的要求,而且接受现有功能的遗漏。一方面,考虑迁移的应用程序是旧的应用程序的准确副本,减少迁移工作是明智的。另一方面,提供不适用于旧技术堆栈的新功能增强利益相关方的信任。这种迁移可以视为进步而并非停滞。


2系统分解有两个必须考虑的决定。
首先,是否通过使用现有的代码库或者完全重写功能来提取微服务。
其次,定义目标架构,并且必须做出决定,微服务是自带前端,还是多个微服务集成在一个UI单体中。

当使用现有的代码库时,该代码库的副本就是跳板。那么给定的部分已经表现出高度的自主性。而且,当项目范围局限于较少人数开发应用时,这种方法可能会取得成功。当挑战是将多个团队分离时,建议将微服务定义为自己的前端。


这需要进一步讨论如何解释微服务的层次。关于三层架构,可以区分两种微服务类型。一方面是只包含数据和应用程序层的微服务(图1)。另一方面还有从数据层到表现层的微服务。


当使用“2层微服务”时,在建立前端的这种多微服务时建立了一个UI单体。这带来了将微服务整合到同一个前端的耦合团队的风险。相比之下,提供自己的前端部分的“全栈微服务”(例如UI碎片)则为团队提供了更高程度的自主权(图2)。


3模型边界保护作为一个起点,建议从中等复杂度的单个上下文开始。这样做的时候,保护即将实现这个上下文的微服务底层模型很重要。因此,应该规定一条规则,即禁止通过数据层访问(如JDBC或直接API调用)从整体数据访问数据。相反,数据应该从后台异步传输到后台的微服务,同时还要在新旧模式之间进行转换。这可以看作两个数据存储的同步,并符合构建防腐层(ACL)的思想,这是一个域驱动设计(DDD)的概念。在这种情况下,ACL可以作为微服务和巨石的模型完整性保护器(图3)。

风险监测任何迁移都有风险。特别是在进行完全重写时,如果新应用程序与现有应用程序相比得到相同的结果,则应使用与业务相关的度量标准(如营业额)进行衡量。然后,通过逐渐将新应用交付给越来越多的客户,控制经济风险。在这一点上,应该考虑诸如Canary Releasing的部署策略。


另外,建议在生产环境中测试微服务,然后再将其推广给客户。这可以通过向微服务提供请求并完全观察他们的行为Shadow Traffic来实现。性能问题可以在不影响应用程序的情况下展开,因为各自的响应被省略。这种做法是由两位专家和文献描述的。


其他措施也可以支持降低云服务迁移过程中的风险。使用诸如特性切换之类的机制在旧的和新的实现之间切换。它们提供了灵活性,仅通过更改配置来控制这一点,而无需重新部署整个应用程序。


5自动化和测试为了减少TTM(上市时间),作为微服务的部署流水线,建议将价值流建模和自动化。在这里,要考虑从代码提交到部署构建的每一步。这确保部署可以经常进行。此外,这从一开始就支持高度的测试覆盖,因为测试也是该流水线的一部分。


在考虑自动化测试时,专家会参考所谓的自动化测试金字塔。测试金字塔由三个测试层组成:单元,服务和UI测试。每层测试的数量减少,导致金字塔形状--许多单元测试和少量UI测试。为了确保多个微服务如预期的那样相互整合,依靠UI测试是合理的。但UI测试对于开发和维护来说是脆弱和昂贵的。这就是为什么在没有UI的情况下单独进行测试非常重要:使用模拟对象自主地测试微服务。借助模拟对象,可以模拟与其他微服务或巨石应用的交互。相应的测试被称为,自动测试金字塔内的服务级别测试。


6敏捷转型引入敏捷方法并立即迁移到微服务是巨大的变化。因此,建议将其分成几个步骤,并寻求逐渐改变。否则动机和定向障碍的风险太高。通过引入Scrum这样的敏捷方法,理想的微服务出现,是随着时间的推移争取团队的自主性。

尽管Scrum主要是在一个跨职能和以产品为中心的团队中解决软件开发过程,大规模的组织也需要采用。Scrum没有提供解决多个敏捷团队协调的解决方案。还有一些坚定的观点认为,对于大型项目来说,应该避免使用灵活的方法来分割产品。随着时间的推移,出现了不同的Scrum和敏捷方法扩展方法。例如,LeSS(大规模Scrum),Nexus和SAFe(缩放敏捷框架)是根据其市场份额为大型组织提供敏捷性的相关方法。


在更大的组织环境中建立敏捷方法时,建议先从一个团队开始,然后再增加越来越多的团队。同样在LeSS中,这被描述为耗时,但却是以功能为中心的团队,同时打破功能孤岛的安全方式。




透明度

此外建议记录产生的非功能性工作,例如在积压工作中实施ACL,并合理安排其他要求。在SAFe中,引入了可以代表上述技术和机制的实施以及迁移工作的推动者的故事。它们确保了透明度,展现了业务与IT之间潜在的相互依赖关系。因此,应根据2位专家的建议,与企业和技术负责人进行优先排序。

图4:敏捷和微服务之路



3、总结

微服务包含组织层面和技术方面。这就是为什么引入微服务涉及两种情况下的措施。如果没有单体考虑,微服务的好处是脆弱的。从纯粹的技术角度来看,微服务可以使用瀑布式软件工程方法来实现。但是,为了充分发挥每个微服务的自主性,它们被嵌入到敏捷文化中。


特别是,拥有多个团队的组织可以从微服务的非技术方面获益。从数据层向前端分解一个系统,将团队分离开来。因此,如果多个团队使用一个前端开发应用程序,那么团队边界在架构中反映最好。这些团队可以自主地加速应用程序的部分。在单体应用程序和分层的团队中,这是更困难的。在这里,复杂的依赖需要协调跨越团队边界的活动。因此TTM下降。


由于敏捷团队由开发人员和非技术人员组成,因此IT和业务需要携手合作。微服务的出现是由于敏捷团队争取自主权。当团队决定转向微服务时,迁移本身没有任何价值,可以向客户交付新功能。尽管如此,微服务迁移工作仍需要优先考虑。这需要透明度。只有不断提高透明度,敏捷性和微服务才能彼此加速。否则,长期不会降低TTM的风险很高。


为了避免在引入微服务时构建未来的传统软件,建立敏捷思维和不断重新思考解决方案很重要。


原文链接:
6 Things to Consider for Microservice Migration

 

这款分布式配置中心,会是微服务的降维打击利器吗?

回复

dataman 发起了问题 • 0 人关注 • 0 个回复 • 217 次浏览 • 2018-01-25 14:22 • 来自相关话题

docker + kubernetes=共生?相爱相杀?

dataman 发表了文章 • 0 个评论 • 138 次浏览 • 2018-01-23 10:59 • 来自相关话题

 





2017年的云计算市场,有一个领域获得了空前的关注 -- Kubernetes。 Kubernetes可以追溯到2014年,当时Google公开发布了该项目的开源代码。2017年,Kubernetes广受欢迎,几乎所有的主要IT供应商都支持这个平台。
 
小数今天推送的这篇文章,为您揭示Kubernetes与Docker容器之间是怎样的关系?对企业客户又意味着什么?
 
 
1
 
Kubernetes是一个开源项目,提供容器编排,部署和管理功能。自 2015 年 7月以来,它一直是由Linux基金会下的云原生计算基金会(CNCF)运营。尽管Kubernetes不再只是Google的一个项目,Google仍然贡献了远大于比其他任何机构的代码量。
 
 将AIX应用程序迁移到云的最佳实践
Kubernetes 2017年如此耀眼,2018年Kubernetes将继续成为一支重要的力量。要理解这点,首先要认识到这项技术和云计算的完美契合之处。 
 
在过去三,四年中,越来越多的企业选择使用Docker容器来部署云工作负载。Docker容器提供的既是运行容器化应用程序的运行时,也是封装和交付容器应用的格式。容器提供了直接在虚拟机管理程序内部改善可移植性和效率的承诺。
 
随着容器使用量的增长,需要对容器集群进行编排,调度和控制。这就是Kubernetes适合的地方。Kubernetes提供了大规模运行容器的编排系统和管理平台。还提供了一系列API抽象,使其他技术可以插入,使平台具有很强的可扩展性,并且能够支持各种不同的供应商部署用例。
 
比其核心编排能力更重要的是,Kubernetes在2017年成为实现多云世界的事实平台。虽然AWS在2017年继续主导公有云,但企业仍然希望能够在多个云上部署和运行应用程序。
 
容器提供了运行应用程序的基本包装,可以在任何支持容器的云上部署。有了Kubernetes,就有了一个平台,可以帮助企业在运行Kubernetes的云或本地部署管理容器的部署和编排。
 云中的Kubernetes
 
一颗种子总会发芽,结出硕果。在作为开源技术的短短3年时间里,Kubernetes成为基于容器的工作负载的默认编排引擎。虽然捐赠的是1.0版本,但是谷歌在大规模运行容器方面有十年的研究和经验。
 
 
Google是否在内部使用Kubernetes?来自Kubernetes博客:“Google上的许多开发人员都是以前在Borg项目上的开发人员。我们已经将Borg的最佳创意融入了Kubernetes,并试图解决用户在多年来与Borg确定的一些痛点。”
 
谷歌在一些内部项目中使用Kubernetes的声音很清晰,且很快就会改变一些现有的关键产品。即使未来需要更好的展示,Kubernetes也可以轻松定制 – 最大的好处是可以根据需要将自定义组件与现有组件进行混合和匹配。
 
以下是Google在过去几年 Kubernetes 的搜索量增长情况:
 
 

 
Google在Kubernetes上运行的Linux容器(LXC)并不是那么容易处理,而且需要掌握更多的专业知识。
 
2017年初,Kubernetes 只支持谷歌云平台(GCP)和谷歌Kubernetes引擎(GKE),但是在一年中,扩展到包括所有三家主要的公有云供应商。
 
二月份,微软正式加入支持Kubernetes的行列,宣布 Azure容器服务支持Kubernetes。去年11月,Kubernetes在亚马逊弹性容器服务(Amazon EKS)首次亮相。
 
除了公有云支持外,CNCF在9月份还宣布了Kubernetes认证服务提供商计划。该计划现在有25个合作伙伴公司开发和销售自己的Kubernetes发行版并提供管理服务。为了确保不同Kubernetes供应商和平台之间的互操作性,CNCF于2017年11月推出了认证Kubernetes计划,目前拥有42个成员公司。
 
 Docker
Kubernetes部署大多使用Docker作为默认的容器引擎,除此之外还有CoreOS的rkt等。就其本身而言,Docker有一个叫做Swarm的自身的编排系统,首次亮相于2014年12月。
 
在许多企业的容器部署中,多数情况是Docker容器引擎正在被使用,Kubernetes被选择作为编排工具,而不是Swarm。10月17日,在与Kubernetes进行了三年的市场竞争之后,Docker Inc.宣布也将支持Kubernetes。
 
要清楚的是,Docker公司并没有放弃自己的Swarm容器编排系统; 相反,它同时支持Swarm和Kubernetes,让企业可以选择想要使用的平台。
 
在接受eWEEK 视频采访时,Docker首席执行官史蒂夫·辛格(Steve Singh)解释了为什么选择拥抱Kubernetes。Singh说:“Kubernetes为我们所做的事情是消除了任何潜在的混乱和冲突。我们有爱Kubernetes的客户,也有爱Docker Swarm的客户,不应该强迫客户在两者之间做出选择,而是让他们选择想要使用他们的东西。 ”
 
 
Kubernetes之前的Docker 让容器变得更酷,更易用。由Docker公司推出的Docker 在LXC功能的扩展之外,增加了多种功能。包括跨机器的可移植部署,版本控制,组件重用以及现在的 Docker Hub ,它提供了“开发测试流水线自动化,100,000个免费应用程序,公共和私有注册中心”。
 
以下是Google for Docker搜索量增长的图表:
 

 
 Kubernetes 1.9和超越
2017年,Kubernetes更新了四个主要版本,增加了新的特性和功能。第一个主要版本是3月27日推出的Kubernetes 1.6,带来了新的可扩展性和稳定性功能。Kubernetes 1.7于6月29日发布,提供了帮助管理和保护容器基础设施的新功能。第三个版本是1.8更新,于9月28日推出,并支持基于角色的访问控制(Role-Based Access Control,RBAC)。
 
Kubernetes 1.9是2017年的最后一次重大更新,于12月15日正式推出。Kubernetes 1.9的亮点是Apps Workloads API,它为 Kubernetes 中长时间运行无状态和有状态工作负载提供了基础。
 
这是Kubernetes转型的一年,2017开源的努力始于一家公有云供应商,终于年底支持所有三家主要的公有云提供商。该项目也从Docker竞争对手的角色转到被Docker拥抱。多云的承诺长久以来只是一个承诺。作为一个可以在任何公有云提供商上启用容器应用程序工作负载的抽象层,随着Kubernetes 2017年的兴起,2018多云承诺将成为现实。
 
 
2
 
Kubernetes正在巩固自己作为事实上的容器编排引擎的地位,而Docker帮助实现了这一点。尽管Docker一直是领先的容器技术,但容器编排市场还没这么清晰。2017年末,随着包括Docker在内的主要云平台提供商支持Kubernetes和一些令人惊讶的CNCF成员资格的增加,这种情况发生了变化。
 
 正确的时机
“时机就是一切”,对于Kubernetes来说,这似乎是正确的。通过让容器更易用,Docker正在推动Kubernetes的发展。事实上,它已经成为每个公司发展的共生关系 。使用Kubernetes的人越多,使用Docker的也会越多,反之亦然。
 
根据 Portworx2017年度容器采购调查 (2017年2月至3月完成),有两项统计数据显示:
“对于拥有超过5000名员工的公司,Kubernetes的使用率为48%,主要编排工具占33%。”
“79%的样本选择Docker作为主要容器技术。”
 
为了进一步加持 Kubernetes 领导者地位,大型云计算和软件供应商们纷纷加入,以支持Docker容器的工作负载。
 
 Kubernetes商业化产品
自从开源以来,Kubernetes有很多商业化产品,在过去的几个月,这个list上取得了重大且令人印象深刻的突破。
 
以Google(Google ContainerEngine),Red Hat(OpenShift),CoreOS(Tectonic),Canonical和 Apprenda 为长期商业供应商(长期以月计)。微软和VMware也已经提供了对Kubernetes的支持,最近已经全面all-in 推出。
 
 2017 Kubernetes 得胜之年
2017年下半年,主要云服务商将Kubernetes添加到其核心产品中。值得注意的公告包括:
亚马逊网络服务(AWS)于八月份以白金会员 (最高级别) 加入了CNCF。虽然AWS加入CNCF与 Kubernetes 没有直接关系,但AWS拥有大量客户在运行容器和Kubernetes。
 
之后,10月份,Cloud Foundry基金会宣布了由Kubernetes提供支持的Cloud Foundry Container Runtime(CFCR),而Pivotal Cloud Foundry(与VMware合作 )则 于10月份在VMworld 宣布了Pivotal Container Service(PKS)。Pivotal和VMware都作为CNCF的白金会员注册; 再次,可用的最高水平。
 
VMware正在与Kubernetes合作的事实是一个明确的信号,Kubernetes和容器希望保持相关性。许多人质疑容器和云计算是否会取代虚拟机。虽然专家认为他们在企业中存在共存的空间,但可以看看VMware这位虚拟化之王的明显转变。
 
在十月之后,Microsoft 将 Azure容器服务 (ACS)更名 为AKS,K代表Kubernetes。这与他们以前的观点有很大的转变,即 ACS的好处之一是它支持多种编排工具 。
 
即使是Docker Inc.也已经屈服,最近在其Docker企业版框架中添加了本地Kubernetes支持。这对Kubernetes来说是一个重大的胜利,并将推动Docker自己的编排平台Docker Swarm的未来发展。
 
Docker甚至委托独立基准测试来对比Swarm和Kubernetes 。两者肯定都有用例,但Kubernetes得到Google支持的事实是经过了战斗性测试的(还记得 PokémonGO吗 ? ),并且拥有巨大的社区支持,企业把它看作标准的容器编排引擎。 
 
 

这对企业意味着什么?
Kubernetes和Docker一直在坚持。随着公司迁移到云端,他们会发现他们有一些需求PaaS或IaaS最适合,还有一些其他需求容器(有些人称之为CaaS)会更适合。
 
为了享受到上云带来的好处,企业正在转向DevOps和云原生开发。采用DevOps时,企业开始使用运行在容器中的微服务,将应用程序构建为独立的组件。这些团队将会变得更小( 亚马逊CTO Werner Vogels 创造了“双比萨团队”(two-pizza team)一词),并且能够独立于应用的其他组件更新其“服务”的功能。
 
通过将开发工作分解为专注于解耦服务的小型团队,企业可以扩展开发工作,并更快地为客户/用户提供价值。现在,已然不是每六个月更新一次的代码库,而是按需随时进行更新。
 
自动化是复杂的抽象,为了使这项工作自动化,提供一个简单,可重复的方式来安全地交付和部署软件,团队会更频繁地执行。
 
技术的抽象和多样使监控成为难题的重要部分。企业拥有数千个独立移动的部件,其中许多可能显示为传统监控解决方案的黑盒子。随着企业迈向云原生,越来越多的应用程序正在云中运行,专门设计并运行良好的监控方法至关重要。
 
2018年将发生什么?Kubernetes给业务需求和企业客户能够带来的改变已经明晰,作为构建和运行云原生应用的平台乘胜追击,能够在多大比例的企业实现软着陆呢?大概套用那句老话是最准确的:前途是光明的,道路是曲折的。
 
 
原文链接:
1、2018 is the year of Kubernetes – with some help from Docker
https://www.tuicool.com/articles/QBFjAf6
2、2017 Year in Review: Kubernetes Enables a Multi-Cloud World
http://www.eweek.com/cloud/2017-year-in-review-kubernetes-enables-a-multi-cloud-world 查看全部
 

微信图片_20180123105002.jpg

2017年的云计算市场,有一个领域获得了空前的关注 -- Kubernetes。 Kubernetes可以追溯到2014年,当时Google公开发布了该项目的开源代码。2017年,Kubernetes广受欢迎,几乎所有的主要IT供应商都支持这个平台。
 
小数今天推送的这篇文章,为您揭示Kubernetes与Docker容器之间是怎样的关系?对企业客户又意味着什么?
 
 
1
 
Kubernetes是一个开源项目,提供容器编排,部署和管理功能。自 2015 年 7月以来,它一直是由Linux基金会下的云原生计算基金会(CNCF)运营。尽管Kubernetes不再只是Google的一个项目,Google仍然贡献了远大于比其他任何机构的代码量。
 
 将AIX应用程序迁移到云的最佳实践
Kubernetes 2017年如此耀眼,2018年Kubernetes将继续成为一支重要的力量。要理解这点,首先要认识到这项技术和云计算的完美契合之处。 
 
在过去三,四年中,越来越多的企业选择使用Docker容器来部署云工作负载。Docker容器提供的既是运行容器化应用程序的运行时,也是封装和交付容器应用的格式。容器提供了直接在虚拟机管理程序内部改善可移植性和效率的承诺。
 
随着容器使用量的增长,需要对容器集群进行编排,调度和控制。这就是Kubernetes适合的地方。Kubernetes提供了大规模运行容器的编排系统和管理平台。还提供了一系列API抽象,使其他技术可以插入,使平台具有很强的可扩展性,并且能够支持各种不同的供应商部署用例。
 
比其核心编排能力更重要的是,Kubernetes在2017年成为实现多云世界的事实平台。虽然AWS在2017年继续主导公有云,但企业仍然希望能够在多个云上部署和运行应用程序。
 
容器提供了运行应用程序的基本包装,可以在任何支持容器的云上部署。有了Kubernetes,就有了一个平台,可以帮助企业在运行Kubernetes的云或本地部署管理容器的部署和编排。
 云中的Kubernetes
 
一颗种子总会发芽,结出硕果。在作为开源技术的短短3年时间里,Kubernetes成为基于容器的工作负载的默认编排引擎。虽然捐赠的是1.0版本,但是谷歌在大规模运行容器方面有十年的研究和经验。
 
 
Google是否在内部使用Kubernetes?来自Kubernetes博客:“Google上的许多开发人员都是以前在Borg项目上的开发人员。我们已经将Borg的最佳创意融入了Kubernetes,并试图解决用户在多年来与Borg确定的一些痛点。”
 
谷歌在一些内部项目中使用Kubernetes的声音很清晰,且很快就会改变一些现有的关键产品。即使未来需要更好的展示,Kubernetes也可以轻松定制 – 最大的好处是可以根据需要将自定义组件与现有组件进行混合和匹配。
 
以下是Google在过去几年 Kubernetes 的搜索量增长情况:
 
 

 
Google在Kubernetes上运行的Linux容器(LXC)并不是那么容易处理,而且需要掌握更多的专业知识。
 
2017年初,Kubernetes 只支持谷歌云平台(GCP)和谷歌Kubernetes引擎(GKE),但是在一年中,扩展到包括所有三家主要的公有云供应商。
 
二月份,微软正式加入支持Kubernetes的行列,宣布 Azure容器服务支持Kubernetes。去年11月,Kubernetes在亚马逊弹性容器服务(Amazon EKS)首次亮相。
 
除了公有云支持外,CNCF在9月份还宣布了Kubernetes认证服务提供商计划。该计划现在有25个合作伙伴公司开发和销售自己的Kubernetes发行版并提供管理服务。为了确保不同Kubernetes供应商和平台之间的互操作性,CNCF于2017年11月推出了认证Kubernetes计划,目前拥有42个成员公司。
 
 Docker
Kubernetes部署大多使用Docker作为默认的容器引擎,除此之外还有CoreOS的rkt等。就其本身而言,Docker有一个叫做Swarm的自身的编排系统,首次亮相于2014年12月。
 
在许多企业的容器部署中,多数情况是Docker容器引擎正在被使用,Kubernetes被选择作为编排工具,而不是Swarm。10月17日,在与Kubernetes进行了三年的市场竞争之后,Docker Inc.宣布也将支持Kubernetes。
 
要清楚的是,Docker公司并没有放弃自己的Swarm容器编排系统; 相反,它同时支持Swarm和Kubernetes,让企业可以选择想要使用的平台。
 
在接受eWEEK 视频采访时,Docker首席执行官史蒂夫·辛格(Steve Singh)解释了为什么选择拥抱Kubernetes。Singh说:“Kubernetes为我们所做的事情是消除了任何潜在的混乱和冲突。我们有爱Kubernetes的客户,也有爱Docker Swarm的客户,不应该强迫客户在两者之间做出选择,而是让他们选择想要使用他们的东西。 ”
 
 
Kubernetes之前的Docker 让容器变得更酷,更易用。由Docker公司推出的Docker 在LXC功能的扩展之外,增加了多种功能。包括跨机器的可移植部署,版本控制,组件重用以及现在的 Docker Hub ,它提供了“开发测试流水线自动化,100,000个免费应用程序,公共和私有注册中心”。
 
以下是Google for Docker搜索量增长的图表:
 

 
 Kubernetes 1.9和超越
2017年,Kubernetes更新了四个主要版本,增加了新的特性和功能。第一个主要版本是3月27日推出的Kubernetes 1.6,带来了新的可扩展性和稳定性功能。Kubernetes 1.7于6月29日发布,提供了帮助管理和保护容器基础设施的新功能。第三个版本是1.8更新,于9月28日推出,并支持基于角色的访问控制(Role-Based Access Control,RBAC)。
 
Kubernetes 1.9是2017年的最后一次重大更新,于12月15日正式推出。Kubernetes 1.9的亮点是Apps Workloads API,它为 Kubernetes 中长时间运行无状态和有状态工作负载提供了基础。
 
这是Kubernetes转型的一年,2017开源的努力始于一家公有云供应商,终于年底支持所有三家主要的公有云提供商。该项目也从Docker竞争对手的角色转到被Docker拥抱。多云的承诺长久以来只是一个承诺。作为一个可以在任何公有云提供商上启用容器应用程序工作负载的抽象层,随着Kubernetes 2017年的兴起,2018多云承诺将成为现实。
 
 
2
 
Kubernetes正在巩固自己作为事实上的容器编排引擎的地位,而Docker帮助实现了这一点。尽管Docker一直是领先的容器技术,但容器编排市场还没这么清晰。2017年末,随着包括Docker在内的主要云平台提供商支持Kubernetes和一些令人惊讶的CNCF成员资格的增加,这种情况发生了变化。
 
 正确的时机
“时机就是一切”,对于Kubernetes来说,这似乎是正确的。通过让容器更易用,Docker正在推动Kubernetes的发展。事实上,它已经成为每个公司发展的共生关系 。使用Kubernetes的人越多,使用Docker的也会越多,反之亦然。
 
根据 Portworx2017年度容器采购调查 (2017年2月至3月完成),有两项统计数据显示:
“对于拥有超过5000名员工的公司,Kubernetes的使用率为48%,主要编排工具占33%。”
“79%的样本选择Docker作为主要容器技术。”
 
为了进一步加持 Kubernetes 领导者地位,大型云计算和软件供应商们纷纷加入,以支持Docker容器的工作负载。
 
 Kubernetes商业化产品
自从开源以来,Kubernetes有很多商业化产品,在过去的几个月,这个list上取得了重大且令人印象深刻的突破。
 
以Google(Google ContainerEngine),Red Hat(OpenShift),CoreOS(Tectonic),Canonical和 Apprenda 为长期商业供应商(长期以月计)。微软和VMware也已经提供了对Kubernetes的支持,最近已经全面all-in 推出。
 
 2017 Kubernetes 得胜之年
2017年下半年,主要云服务商将Kubernetes添加到其核心产品中。值得注意的公告包括:
亚马逊网络服务(AWS)于八月份以白金会员 (最高级别) 加入了CNCF。虽然AWS加入CNCF与 Kubernetes 没有直接关系,但AWS拥有大量客户在运行容器和Kubernetes。
 
之后,10月份,Cloud Foundry基金会宣布了由Kubernetes提供支持的Cloud Foundry Container Runtime(CFCR),而Pivotal Cloud Foundry(与VMware合作 )则 于10月份在VMworld 宣布了Pivotal Container Service(PKS)。Pivotal和VMware都作为CNCF的白金会员注册; 再次,可用的最高水平。
 
VMware正在与Kubernetes合作的事实是一个明确的信号,Kubernetes和容器希望保持相关性。许多人质疑容器和云计算是否会取代虚拟机。虽然专家认为他们在企业中存在共存的空间,但可以看看VMware这位虚拟化之王的明显转变。
 
在十月之后,Microsoft 将 Azure容器服务 (ACS)更名 为AKS,K代表Kubernetes。这与他们以前的观点有很大的转变,即 ACS的好处之一是它支持多种编排工具 。
 
即使是Docker Inc.也已经屈服,最近在其Docker企业版框架中添加了本地Kubernetes支持。这对Kubernetes来说是一个重大的胜利,并将推动Docker自己的编排平台Docker Swarm的未来发展。
 
Docker甚至委托独立基准测试来对比Swarm和Kubernetes 。两者肯定都有用例,但Kubernetes得到Google支持的事实是经过了战斗性测试的(还记得 PokémonGO吗 ? ),并且拥有巨大的社区支持,企业把它看作标准的容器编排引擎。 
 
 

这对企业意味着什么?
Kubernetes和Docker一直在坚持。随着公司迁移到云端,他们会发现他们有一些需求PaaS或IaaS最适合,还有一些其他需求容器(有些人称之为CaaS)会更适合。
 
为了享受到上云带来的好处,企业正在转向DevOps和云原生开发。采用DevOps时,企业开始使用运行在容器中的微服务,将应用程序构建为独立的组件。这些团队将会变得更小( 亚马逊CTO Werner Vogels 创造了“双比萨团队”(two-pizza team)一词),并且能够独立于应用的其他组件更新其“服务”的功能。
 
通过将开发工作分解为专注于解耦服务的小型团队,企业可以扩展开发工作,并更快地为客户/用户提供价值。现在,已然不是每六个月更新一次的代码库,而是按需随时进行更新。
 
自动化是复杂的抽象,为了使这项工作自动化,提供一个简单,可重复的方式来安全地交付和部署软件,团队会更频繁地执行。
 
技术的抽象和多样使监控成为难题的重要部分。企业拥有数千个独立移动的部件,其中许多可能显示为传统监控解决方案的黑盒子。随着企业迈向云原生,越来越多的应用程序正在云中运行,专门设计并运行良好的监控方法至关重要。
 
2018年将发生什么?Kubernetes给业务需求和企业客户能够带来的改变已经明晰,作为构建和运行云原生应用的平台乘胜追击,能够在多大比例的企业实现软着陆呢?大概套用那句老话是最准确的:前途是光明的,道路是曲折的。
 
 
原文链接:
1、2018 is the year of Kubernetes – with some help from Docker
https://www.tuicool.com/articles/QBFjAf6
2、2017 Year in Review: Kubernetes Enables a Multi-Cloud World
http://www.eweek.com/cloud/2017-year-in-review-kubernetes-enables-a-multi-cloud-world

实录分享|微服务落地践行渐进,4个Q&A一窥金融微服务现状(附PPT下载)

dataman 发表了文章 • 0 个评论 • 147 次浏览 • 2018-01-19 11:10 • 来自相关话题

1月13日,中国双态运维用户大会在北京举办。来自银行、保险、证券、政府、央企等多个行业的330多位企业用户参加,其中工商银行信息科技部副总经理张艳,国泰君安信息技术部总经理俞枫、海关总署科技发展司运行安全处处长张芳、平安科技系统运营部总经理陈亚殊等分别发表了演讲。本文为数人云CEO王璞在双态运维用户大会DevOps、容器与微服务分论坛上的演讲实录。演讲结束,与在座金融客户展开了精彩的Q&A分享。


容器、微服务、DevOps三者,业内的共识是密不可分。没有微服务,DevOps落地不下去,没有容器,DevOps也无法真正实现敏捷运维、自动化运维。DevOps、容器、微服务为更好的构建PaaS提供了方法论和技术手段。
 
 
1、PaaS之承上启下

PaaS作为云计算的承上启下要素,向上支撑各环境应用,向下跟IaaS、计算环境、计算资源对接,是企业云化的必由之路。
 
>>>>PaaS三大技术趋势

1.应用容器化,容器正在成为云计算原生应用的标准交付方式。

2.微服务网格化,随着企业对微服务的认知越来越深入,下一代微服务着重把应用管理作为核心。因为企业应用一定要有很强的管理在微服务架构上,不能让应用去“裸奔”。数人云没有提微服务化,因为微服务化已经是不争的事实。应用微服务缺乏强大的管理,需要服务网格这样的下一代微服务技术。

3.行业生态化,PaaS技术本质上是支持应用的,应用跟业务紧密结合,所以PaaS最终是要和业务层面融合,行业需要生态化。>>>>PaaS落地三大要素:

PaaS要在企业客户方面落地不可或缺三要素:规模化、统一化、标准化。企业客户落地云计算平台、技术,本质上是希望提高效率,对业务有更好的敏捷支撑。

所有应用,比如容器应用、微服务应用,都实现标准化。标准化以后进行统一化管理,包括部署、发布、故障恢复、监控告警等都实现统一化管理。最后实现模块化,整个系统都是轻量的,微小模块化的。只有基于这三点的PaaS平台和云计算平台,才能够让IT系统真正实现敏捷轻量,提高IT对业务支撑的效果。
 
 
2、企业IT架构转型之开发&运维

企业客户目前在架构转型应用中面临的现状是,企业里大量传统应用,客户希望先实现轻量的单体架构,即摆脱很多中间件,摆脱外部服务,MVC架构、单体复杂架构等首先实现轻量化。

数人云日常接触的客户中,走的比较靠前的客户已经在用Spring Cloud、Dubbo等架构,部分客户相当数量的应用已经微服务化,不过处于中间状态,正在考虑评估微服务架构的客户比例还是最大。总之,企业目前的现状是为服务应用、轻量单体应用,以及传统的巨石应用并存。

在架构转型过程中,正确和常态的路径一定是一步步走过来,而不是传统架构丢掉直接上微服务。
 
>>>>DevOps和容器@轻量单体应用架构

在单体应用架构下,DevOps、容器帮助企业实现敏捷IT。首先,持续集成持续交付CI/CD,只要应用是相对轻量的,就能加快中间件应用。CI/CD其中重要的一点是变更发布管理。
数人云某客户上了容器的应用都是轻量化的,基于 Tomcat 和微服务的应用。当基于容器实现快速发布以后,企业发现,所有发布里有一半的发布失败是由于配置不正确引起的。所以,如果没有发布变更管理,发布失败的中间环节有方方面面的因素。


当基于容器实现快速发布之后,容器对环境的异构做了一层屏蔽,这时如果出现处理的问题就是配置管理的问题了,由于涉及不同的环境和应用,配置环境变成应用发布很容易出错的环节。
 
>>>>DevOps和容器@微服务应用架构

数人云做了企业客户微服务落地状况的调研(微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑),在报告中,有15%左右的企业引入了Spring Cloud、Dubbo。微服务在企业里首当其冲的是敏捷开发,因为微服务是一种切实的敏捷开发的方法。
敏捷开发在IT界已经推广多年,但很多时候敏捷开发推的都是方法论,比如Scrum。微服务是一套切实能够落地到IT人员、开发人员开发过程中的实践方法,这是微服务首当其冲的好处,很多企业的开发部门对微服务非常欢迎。不过,15%还是偏小的一个采用比例,微服务还不是企业客户主流的IT架构。


开发人员都比较欢迎微服务,因为能够提升开发效率,落地敏捷开发,但微服务的阻碍还是不小的,微服务对开发运维来说,带来的复杂度急剧上升。传统运维管理的服务器数量、应用数量有限。企业决定采用微服务本身就表明业务很复杂,单体应用做传统的瀑布式开发效率太低,微服务将应用拆分成较小的模块,因此微服务应用一旦上线,程序的数量呈现爆炸式增长。


例如,数人云某个传统企业的客户,目前部署了微服务相关的应用,基于Spring Cloud、Spring Boot,跑在几千个容器上,几千个容器如果通过传统运维方式去管理的话几乎是不可能的。这就是很多微服务无法落地的原因——很多企业客户缺乏相应的运维能力,没有相应的平台、工具、方式、方法管理微服务应用。
 

>>>>微服务落地的必要条件

微服务应用落地,首当其冲是配套工具链的完善。开发人员采用微服务的影响相对改变小一些。采用SpringCloud或者Dubbo、gRPC等,只是开发框架上的并更。其他开发流程如代码托管、代码审查、测试等并不涉及,所以开发流程相对简单。但微服务对运维功能的要求就会复杂,相应的快速配置能力、完备的监控能力、快速部署能力等对传统运维来说都是缺失的,容器能够补足这方面的能力,让运维部门具有DevOps的能力。

 
关于微服务的拆分,其实是业务部门需要真正解决的问题。微服务对组织上也有变更,将团队化整为零。通常每个单独的微服务程序都由7-10人的小团队来负责维护,这些都是微服务落地的必要条件。

 
对于数人云来说,直接能够给客户提供的帮助,首先是工具链方面,数人云产品层面具备丰富的微服务配套工具链,从监控、日志、调度、故障自动化修复等等都有完备的工具链。在落地方法上,数人云搭建了自己的生态圈,和很多合作伙伴合作,例如跟埃森哲公司在合作,帮助企业客户落地微服务,进行业务的梳理。
 

>>>>容器和微服务共生

容器技术补齐了微服务相关的工具链,对企业全面向云计算转型提供了很大帮助。应用架构是微服务分布式的,相应的运维也要有自动化、敏捷运维的能力。微服务跑在容器上才能发挥它最好的特性。容器是目前最流行的应用环境,基于容器的微服务部署和更新更快,更轻量,服务之间的调用、服务发现、负载均衡等更灵活。


不过,微服务不是万能的。简单的业务场景单体应用其实足够,微服务一定是应用在复杂的业务场景下,只有复杂的业务场景才有很大的维护成本、维护压力,微服务是用来降低复杂业务场景的维护成本。>>>>基于容器云的微服务运行时管理体系

一个完整的微服务管理体系,除了开发框架之外,对运维部门来说,运维微服务应用最基本的路由、负载均衡等功能,容器可以提供,不过容器提供的只是一部分跟微服务相关的能力和工具链。周围还有一大批需要配套的工具,比如配置管理、API网关、注册发现、应用监控等等。这里的监控不是容器CPU内存的监控,而是业务逻辑的监控,更准确一点是全链路跟踪的全链路监控。容器满足了微服务运行时管理的需求,不过周边许多权限、网关、配置等尚无余力满足。

>>>>统一配置中心是微服务体系的核心

统一配置管理,是微服务落地时很核心的点。要在平台工具上落地微服务首先要具备快速配置能力,因为客户采用微服务和容器平台以后,很快会发现50%以上的发布失败是因为配置没搞对,因此配置管理是微服务里首当其冲的问题。

因为每个企业客户都有开发环境、测试环境、生产环境等很多环境,同一个应用不同版本在不同环境下的配置不同。几何级数的配置项、配置元素的增长会导致配置管理的复杂度急剧上升,需要统一的配置中心进行管理。数人云在帮助企业客户落地微服务时,首先会做的是把配置搞定,没有灵活快速的配置管理能力,微服务运行不起来。>>>>变更发布管理(灰度发布 v.s. 蓝绿部署)

在发布管理方面,数人云帮助企业落地的发布管理主要是蓝绿部署,因为很多企业的应用本身不支持灰度发布。蓝绿部署也是切切实实的快速发布,发布用变更窗口的方式来实现。

例如,周五晚上12点起进行发布变更,12点就要停服务中心。蓝绿部署可以显著地缩短服务不可用的变更窗口。怎么做呢?客户在线上有两个版本,蓝版本和绿版本。现在负载均衡器将流量指向对外提供服务的绿版本,蓝版本作为备用的方案。同时,新程序往蓝版本上部署推送,更新时只需要把流量切换到蓝版本。发布流程最后简化为只需要进行流量的切换。流量可以快速切换,中间的窗口期只有短短几分钟,如果流量切换过来一切正常发布即完成,如果流量切换过来发现问题,可以再将流量切回去。这样开发人员、运维人员不必当场熬夜去修复,极大地减轻了发布的压力。


传统发布方式下,每次变更窗口有好几个应用排队发布,一个应用发布完成后才可以发布下一个应用,一旦中间某一个应用发布失败现场修复的压力非常大,短短的发布窗口需要几个小时内完成抢修,非常不可控,团队经常需要晚上熬夜排队。而结果往往等了半天,前面的应用没发布成功,后面的还得继续排队等。
 


3、金融行业之践行渐进

数人云在金融、能源、制造、快消、政企等行业的基础上,继续深耕强监管、强安全,高复杂度的金融行业。以某商业银行为例,数人云帮助落地了大规模微服务容器平台。该商业银行近年来互联网业务发展迅猛,原有系统架构无法支撑其未来规划。2016年6月开始全面实施应用微服务化,已实现蓝绿发布。


首先,营销系统全部是轻量化的应用,基于Spring Boot、Tomcat、SpringCloud等,跑在容器平台上。该银行对外营销频次非常高,通过线上微信公众号、手机APP、线上门户、合作伙伴等渠道,每月对外营销达上百场。

客户背景和规

每次营销活动或多或少都对IT系统有变更,哪怕是配置变更,因此每次营销活动对IT系统都是一次不小的挑战。发布的时候仅仅靠容器是不够的,需要实现模板的批量发布。每次发布看起来只是一个个的容器程序,实则不然,其实是一组组一批批的容器,只有帮客户做到批量的应用发布,才能显著提升发布效率。


蓝绿部署方面,该银行密集的线上营销中,每一天会有一个重点营销活动,那么营销活动的流量如何分到特别的人群、区域?在后台应用的上千个实例中,并不是每一个实例都分配同等的流量,要通过流量分发,做线上流量控制。数人云借鉴Google做灰度发布的方式为客户提供图形化的流量控制,这和微服务实施后的限流分流是息息相关的。

另外,该银行客户的数据流量非常大,对日志收集带来非常大的的压力。数人云建议客户将应用程序的日志全部交给Kafka采集,Kafka可以做到很大数据流量的分布式消息应用。


分布式数据传输分布式消息应用很难保证每一个消息都可靠地传递。Kafka有两种模式:一种保证消息传递至少一次,但也可能多次,对很大的日志量来说偶尔丢一两条可以忽略不计。Kafka的并发量很大,可能带来偶尔很小的数据量丢失,也可能带来日志的乱序,这在分布式系统下都是可以容忍的,“鱼和熊掌不可兼得”。


关于快速建立支撑微服务体系,数人云有几点总结:
1.开发框架不能用重量级的应用体系,要么是轻量化单体架构的Tomcat等,要么采用Spring Cloud等微服务架构。

2.要有微服务平台,具备快速配置管理能力、部署能力、监控能力、应用管理能力等配套管理能力。很多企业的痛点是,开发人员快速学习微服务开发技术,基于Spring Cloud做业务系统后,业务系统无法上线,因为运维部门缺乏配套的工具、平台支撑微服务线上运行管理。

3.DevOps融合,平台管理需要把链条全打通,实现快速发布、快速上线、自动修复等。容器经过几年的普及企业已经相对了解,但容器本身是纯技术平台,基于容器、DevOps的落地还有很长的路要走。>>>>数人云微服务On PaaS 产品体系


数人云现在的重点是微服务、轻量单体应用。以前数人云帮企业客户落地重应用的容器平台,但后来发现价值不大,反而对企业来说,除了维护重的应用外还需要维护容器,容器平台并不能实现自动化运维。经过几年的实践和摸索,数人云跟企业客户达成的共识是,传统应用不经过改造无法上到云PaaS平台。


 轻量架构下的应用如何基于PaaS平台支撑?以敏捷开发为例,企业客户通常选择 Spring Cloud、gRPC 等主流的开发框架,然后在微服务工具链层面配置监控、报警、部署、快速发布等方方面面的能力,最下面承载的则是容器平台。


数人云现在还可以帮助客户落地服务网格化技术。它能够进行异构架构的兼容,gRPC就是服务网格的一部分,Google推的 Istio,Linkerd的Kubernetes 都支持 gRPC,gRPC成为通讯协议的一部分。基于通讯协议相应周边的管理,在服务网格这一层可以做灰度发布、A/B测试、流量控制、高级熔断、加密、白/黑名单机制、权限访问控制等等。


服务网格被称作下一代的微服务,因为用了服务网格以后,所有微服务管理的诉求都自动化地满足了。80%-90%的应用管理需求都在服务网格里自动涵盖。这对开发人员来讲,微服务开发的门槛急剧降低,不需要考虑未来应用上线时流量控制、灰度发布等等,只需要考虑业务。数人云微服务On PaaS 目的就是帮助企业客户降低微服务架构、上云转型的门槛。
 

Q1:感觉对DevOps的理解不太到位,能不能具体地讲一下?A1:DevOps准确来讲,现在业内还没有统一的认识。互联网公司的DevOps目前是比较统一的,比如Goolge,但是互联网公司的DevOps,我个人理解没办法在企业直接落地。


在Google,程序员不止要负责应用的开发,还要负责相应的测试,单元测试、集成测试等等。另外,应用的部署、发布、上线也是开发人员自己做。所以互联网公司讲DevOps,更多讲的是开发运维的融合。我之前在Google时,不仅要做代码开发,也要把测试的代码全写出来。


Google有一个理念,开发人员每写一行业务代码,测试代码要写十行。然后,开发人员利用各种发布平台定期发布,比如每周做发布,在Google 运维的人员叫“SRE”。SRE部门准备好各种平台,开发人员可以用这些平台做发布、监控、日志管理等工作。


Google目前有三万名左右的IT人员,其中SRE的运维人员只有一千多,比例很低。所以在Google运维人员不可能帮每一个开发人员或者业务部门做上线。像传统IT开发人员提工单给运维,在Google是不可能的。Google这种做法,它让开发做更多的事情,运维人员很少,只是负责维护平台。所以,Google一千多人管理着几百万台服务器,平均每人管两千台。


但传统企业目前不是这样,传统企业开发和运维之间壁垒比较大。数人云帮助客户落地DevOps 时,基于的理念是,不要破坏现有开发的流程。DevOps应该是开发和运维深度融合才能做到的。讲DevOps,首先要讲理念、组织的变革,但是要想把文化变革、组织变革打破要很长时间。


从落地的角度,DevOps更多落地在运维部门,很具象的工作就是,帮助运维部门去实现DevOps的能力,比如快速部署、快速上线,应用的快速配置,自动化管理能力、故障的自动化处理等等。把以前的运维工作尽可能的自动化,提高效率,这是狭义的DevOps理念,也是我们现在接触到的。数人云不会帮客户落地像互联网公司那样的DevOps,开发做很多事情,运维可做的很少,并不是这样的。


 Q&A
Q2:微服务适合复杂的场景,那么一个简单的促销是不是适合?微服务有多“微”呢?微服务和ESB 服务相比,有什么差别?A2:第一个促销场景,促销场景本身有些条件,促销很重要一点就是必须特别频繁,促销内容在平台要发生变化。比如,今天的促销内容和明天的不太一样,或者这周的促销和下周的不太一样,业务平台需要频繁变更,这时候微服务是适合的。


因为微服务是一种敏捷开发的落地实践方法,只要业务频繁变更,对开发的要求就必须敏捷开发,快速实现。所以,只要业务场景在不停地快速变化,促销又是互联网线上的方式,肯定是适合的。

 
关于复杂性,如果业务逻辑简单,逻辑变化少,并不适合微服务。比如数人云和很多银行客户合作,银行核心系统很复杂,但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”,就是银行核心系统的功能越来越单一,越来越瘦,并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂,但业务不会频繁变化,也不一定要上到微服务场景下。复杂的业务系统,业务需求又不停变化,这种场景适合微服务。


第二个问题是和ESB 比,服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来,很多不同的业务系统都上到ESB,互相的权限通过ESB打通。从功能角度讲,ESB和服务网格之间很相像,不同点在于ESB是传统架构下的,并没有考虑频繁迭代、流量集中爆发等问题。


但是微服务情况下,整个之间的互相请求、依赖、通讯等等都会进行统一的管理,这种情况下也很像ESB把不同业务之间的流量进行统一管理,但是服务网格更看重的是面向大规模的控制,那流量突发怎么做限流,或者突然故障怎么做熔断等等。最本质的问题是类似的,但是具体的问题表象和需求不同。 Q&A 
Q3:在实际部署过程中,PaaS平台在底层资源的调用一定要用分布式云架构,传统主机是否可以?两者在最后效果上有没有什么异同?A3:数人云当初两种情况都有,有些场景比如业务量比较大,企业客户为了减少复杂度,容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理,把PaaS落地到IaaS上,两种情况都有。


这其中的考虑是,首先业务量大如果再引入虚拟化这一层会引来额外的复杂度,此时用物理服务器更好。其次,客户有很大规模的物理服务器,直接在上面部署PaaS,在物理服务器上去调用。

 
第三种,资源动态的调整或资源频繁调配,这个场景很常见,需要IaaS。比如银行客户,内部业务系统分不同的域,不同域的业务复杂性随时间变化经常会发生变化,需要不停地做资源动态的调整。如果用物理机太麻烦,企业客户会选择下面有一层IaaS来做。


基于PaaS也能做一部分的资源动态调配,但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度,PaaS平台是按照应用程序来划分,IaaS的资源划分是按照业务系统。


 Q&A 
Q4:微服务重新开发,最佳的开发框架或者实践有什么可以分享的?第二,旧有的系统改造到微服务这块有没有什么经验?第三,DevOps以前也有很多像敏捷开发的方法论,它们之间有没有什么关系?A4:首先第一个问题,微服务的开发框架。企业客户在做选择时都希望降低风险,选最主流的框架,现在看最主流的开发框架就是Spring cloud,这也是业界的自然选择结果。其他语言也都有些微服务开发,但是用的人少一些。如果是Java应用,目前比较好的选择是Spring Cloud,也有很多客户用了Dubbo,其他架构都是偏小众的架构,主要还是看客户自己的需求。


第二个问题,传统业务要转到微服务架构上,一定要循序渐进。比如Java应用,首先Java中间件的应用,先脱掉,不要再基于这么重的Java中间件。目前相对流行的是Spring Boot这套逻辑。


有了轻量的单体化应用之后(基于Tomcat),往后走基于微服务的框架,上到Spring Boot,再上到Spring Cloud,这是比较平滑的方式。Spring Boot 在很企业客户中用的非常多,是很方便的一套单体开发架构。

 
企业客户目前的现状是老的应用很多,不会一次就改造完,传统的应用可以先选择一部分容易转的转到轻量单体架构上,然后再转到微服务框架上。目前企业客户是轻量的单体架构、微服务架构,以及大量传统的架构应用并存。老的架构应用目前上不到PaaS平台,只有轻量的单体化加微服务应用才能上到PaaS平台。



现在业内的共识是,微服务、容器、DevOps这三者是密不可分的。微服务更多是针对开发人员,是一种真正落地的云开发方法。很多企业客户也讲敏捷开发,派团队成员学习敏捷开发的方法论,但是敏捷开发仍然无法在企业当中落地。


这是因为,只学会了方法,但没办法落地到具体的编程,即开发环节上去,自然没办法做到敏捷开发。很多开发者回来写的程序依然是J2EE。J2EE 编程的理念和方法并不是敏捷开发的,是偏向于瀑布式的。

微服务是具体的开发环节上的敏捷开发方法,开发能力化整为零,每个团队做简单、具象、单一的逻辑。微服务首先是一个具像的敏捷开发方法,实践方法。

微服务在落地时,比如程序运行时,复杂度很高,因为不是一个程序,是一批程序一起运行,对运维的管理就比较复杂,这时候可以利用容器实现微服务应用的自动化管理。微服务一般都会上到容器,因为微服务应用不再是单体的部署方式,不再是部署到Java中间件上。基于微服务架构,几百个进程进来,用容器的方式实现快速部署动态调度,微服务部署到容器上,实现基础的轻量化运维。


轻量化运维,快速部署、自动化调度,逐步往DevOps方向走。DevOps更多强调自动化的运维能力,提高运维的效率,快速部署,出了问题自动化修复。需要用到工具和平台,这就是数人云现在帮客户去做的。


把微服务业务在运行时缺失的管理方式方法、工具平台,工具链补齐。首先是配置管理能力、完备的监控能力等等,普及之后运维人员就有能力来管微服务应用。这其实是DevOps里面最狭义的,让运维的能力变得轻量。


如果要真正实现DevOps,就像目前一些互联网公司做到的,开发和运维真正的深度融合在一起。企业目前的运维一般不具有编程能力,所以真正的DevOps还需要很长时间去落地。

  查看全部
1月13日,中国双态运维用户大会在北京举办。来自银行、保险、证券、政府、央企等多个行业的330多位企业用户参加,其中工商银行信息科技部副总经理张艳,国泰君安信息技术部总经理俞枫、海关总署科技发展司运行安全处处长张芳、平安科技系统运营部总经理陈亚殊等分别发表了演讲。本文为数人云CEO王璞在双态运维用户大会DevOps、容器与微服务分论坛上的演讲实录。演讲结束,与在座金融客户展开了精彩的Q&A分享。


容器、微服务、DevOps三者,业内的共识是密不可分。没有微服务,DevOps落地不下去,没有容器,DevOps也无法真正实现敏捷运维、自动化运维。DevOps、容器、微服务为更好的构建PaaS提供了方法论和技术手段。
 
 
1、PaaS之承上启下

PaaS作为云计算的承上启下要素,向上支撑各环境应用,向下跟IaaS、计算环境、计算资源对接,是企业云化的必由之路。
 
>>>>PaaS三大技术趋势

1.应用容器化,容器正在成为云计算原生应用的标准交付方式。

2.微服务网格化,随着企业对微服务的认知越来越深入,下一代微服务着重把应用管理作为核心。因为企业应用一定要有很强的管理在微服务架构上,不能让应用去“裸奔”。数人云没有提微服务化,因为微服务化已经是不争的事实。应用微服务缺乏强大的管理,需要服务网格这样的下一代微服务技术。

3.行业生态化,PaaS技术本质上是支持应用的,应用跟业务紧密结合,所以PaaS最终是要和业务层面融合,行业需要生态化。>>>>PaaS落地三大要素:

PaaS要在企业客户方面落地不可或缺三要素:规模化、统一化、标准化。企业客户落地云计算平台、技术,本质上是希望提高效率,对业务有更好的敏捷支撑。

所有应用,比如容器应用、微服务应用,都实现标准化。标准化以后进行统一化管理,包括部署、发布、故障恢复、监控告警等都实现统一化管理。最后实现模块化,整个系统都是轻量的,微小模块化的。只有基于这三点的PaaS平台和云计算平台,才能够让IT系统真正实现敏捷轻量,提高IT对业务支撑的效果。
 
 
2、企业IT架构转型之开发&运维

企业客户目前在架构转型应用中面临的现状是,企业里大量传统应用,客户希望先实现轻量的单体架构,即摆脱很多中间件,摆脱外部服务,MVC架构、单体复杂架构等首先实现轻量化。

数人云日常接触的客户中,走的比较靠前的客户已经在用Spring Cloud、Dubbo等架构,部分客户相当数量的应用已经微服务化,不过处于中间状态,正在考虑评估微服务架构的客户比例还是最大。总之,企业目前的现状是为服务应用、轻量单体应用,以及传统的巨石应用并存。

在架构转型过程中,正确和常态的路径一定是一步步走过来,而不是传统架构丢掉直接上微服务。
 
>>>>DevOps和容器@轻量单体应用架构

在单体应用架构下,DevOps、容器帮助企业实现敏捷IT。首先,持续集成持续交付CI/CD,只要应用是相对轻量的,就能加快中间件应用。CI/CD其中重要的一点是变更发布管理。
数人云某客户上了容器的应用都是轻量化的,基于 Tomcat 和微服务的应用。当基于容器实现快速发布以后,企业发现,所有发布里有一半的发布失败是由于配置不正确引起的。所以,如果没有发布变更管理,发布失败的中间环节有方方面面的因素。


当基于容器实现快速发布之后,容器对环境的异构做了一层屏蔽,这时如果出现处理的问题就是配置管理的问题了,由于涉及不同的环境和应用,配置环境变成应用发布很容易出错的环节。
 
>>>>DevOps和容器@微服务应用架构

数人云做了企业客户微服务落地状况的调研(微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑),在报告中,有15%左右的企业引入了Spring Cloud、Dubbo。微服务在企业里首当其冲的是敏捷开发,因为微服务是一种切实的敏捷开发的方法。
敏捷开发在IT界已经推广多年,但很多时候敏捷开发推的都是方法论,比如Scrum。微服务是一套切实能够落地到IT人员、开发人员开发过程中的实践方法,这是微服务首当其冲的好处,很多企业的开发部门对微服务非常欢迎。不过,15%还是偏小的一个采用比例,微服务还不是企业客户主流的IT架构。


开发人员都比较欢迎微服务,因为能够提升开发效率,落地敏捷开发,但微服务的阻碍还是不小的,微服务对开发运维来说,带来的复杂度急剧上升。传统运维管理的服务器数量、应用数量有限。企业决定采用微服务本身就表明业务很复杂,单体应用做传统的瀑布式开发效率太低,微服务将应用拆分成较小的模块,因此微服务应用一旦上线,程序的数量呈现爆炸式增长。


例如,数人云某个传统企业的客户,目前部署了微服务相关的应用,基于Spring Cloud、Spring Boot,跑在几千个容器上,几千个容器如果通过传统运维方式去管理的话几乎是不可能的。这就是很多微服务无法落地的原因——很多企业客户缺乏相应的运维能力,没有相应的平台、工具、方式、方法管理微服务应用。
 

>>>>微服务落地的必要条件

微服务应用落地,首当其冲是配套工具链的完善。开发人员采用微服务的影响相对改变小一些。采用SpringCloud或者Dubbo、gRPC等,只是开发框架上的并更。其他开发流程如代码托管、代码审查、测试等并不涉及,所以开发流程相对简单。但微服务对运维功能的要求就会复杂,相应的快速配置能力、完备的监控能力、快速部署能力等对传统运维来说都是缺失的,容器能够补足这方面的能力,让运维部门具有DevOps的能力。

 
关于微服务的拆分,其实是业务部门需要真正解决的问题。微服务对组织上也有变更,将团队化整为零。通常每个单独的微服务程序都由7-10人的小团队来负责维护,这些都是微服务落地的必要条件。

 
对于数人云来说,直接能够给客户提供的帮助,首先是工具链方面,数人云产品层面具备丰富的微服务配套工具链,从监控、日志、调度、故障自动化修复等等都有完备的工具链。在落地方法上,数人云搭建了自己的生态圈,和很多合作伙伴合作,例如跟埃森哲公司在合作,帮助企业客户落地微服务,进行业务的梳理。
 

>>>>容器和微服务共生

容器技术补齐了微服务相关的工具链,对企业全面向云计算转型提供了很大帮助。应用架构是微服务分布式的,相应的运维也要有自动化、敏捷运维的能力。微服务跑在容器上才能发挥它最好的特性。容器是目前最流行的应用环境,基于容器的微服务部署和更新更快,更轻量,服务之间的调用、服务发现、负载均衡等更灵活。


不过,微服务不是万能的。简单的业务场景单体应用其实足够,微服务一定是应用在复杂的业务场景下,只有复杂的业务场景才有很大的维护成本、维护压力,微服务是用来降低复杂业务场景的维护成本。>>>>基于容器云的微服务运行时管理体系

一个完整的微服务管理体系,除了开发框架之外,对运维部门来说,运维微服务应用最基本的路由、负载均衡等功能,容器可以提供,不过容器提供的只是一部分跟微服务相关的能力和工具链。周围还有一大批需要配套的工具,比如配置管理、API网关、注册发现、应用监控等等。这里的监控不是容器CPU内存的监控,而是业务逻辑的监控,更准确一点是全链路跟踪的全链路监控。容器满足了微服务运行时管理的需求,不过周边许多权限、网关、配置等尚无余力满足。

>>>>统一配置中心是微服务体系的核心

统一配置管理,是微服务落地时很核心的点。要在平台工具上落地微服务首先要具备快速配置能力,因为客户采用微服务和容器平台以后,很快会发现50%以上的发布失败是因为配置没搞对,因此配置管理是微服务里首当其冲的问题。

因为每个企业客户都有开发环境、测试环境、生产环境等很多环境,同一个应用不同版本在不同环境下的配置不同。几何级数的配置项、配置元素的增长会导致配置管理的复杂度急剧上升,需要统一的配置中心进行管理。数人云在帮助企业客户落地微服务时,首先会做的是把配置搞定,没有灵活快速的配置管理能力,微服务运行不起来。>>>>变更发布管理(灰度发布 v.s. 蓝绿部署)

在发布管理方面,数人云帮助企业落地的发布管理主要是蓝绿部署,因为很多企业的应用本身不支持灰度发布。蓝绿部署也是切切实实的快速发布,发布用变更窗口的方式来实现。

例如,周五晚上12点起进行发布变更,12点就要停服务中心。蓝绿部署可以显著地缩短服务不可用的变更窗口。怎么做呢?客户在线上有两个版本,蓝版本和绿版本。现在负载均衡器将流量指向对外提供服务的绿版本,蓝版本作为备用的方案。同时,新程序往蓝版本上部署推送,更新时只需要把流量切换到蓝版本。发布流程最后简化为只需要进行流量的切换。流量可以快速切换,中间的窗口期只有短短几分钟,如果流量切换过来一切正常发布即完成,如果流量切换过来发现问题,可以再将流量切回去。这样开发人员、运维人员不必当场熬夜去修复,极大地减轻了发布的压力。


传统发布方式下,每次变更窗口有好几个应用排队发布,一个应用发布完成后才可以发布下一个应用,一旦中间某一个应用发布失败现场修复的压力非常大,短短的发布窗口需要几个小时内完成抢修,非常不可控,团队经常需要晚上熬夜排队。而结果往往等了半天,前面的应用没发布成功,后面的还得继续排队等。
 


3、金融行业之践行渐进

数人云在金融、能源、制造、快消、政企等行业的基础上,继续深耕强监管、强安全,高复杂度的金融行业。以某商业银行为例,数人云帮助落地了大规模微服务容器平台。该商业银行近年来互联网业务发展迅猛,原有系统架构无法支撑其未来规划。2016年6月开始全面实施应用微服务化,已实现蓝绿发布。


首先,营销系统全部是轻量化的应用,基于Spring Boot、Tomcat、SpringCloud等,跑在容器平台上。该银行对外营销频次非常高,通过线上微信公众号、手机APP、线上门户、合作伙伴等渠道,每月对外营销达上百场。

客户背景和规

每次营销活动或多或少都对IT系统有变更,哪怕是配置变更,因此每次营销活动对IT系统都是一次不小的挑战。发布的时候仅仅靠容器是不够的,需要实现模板的批量发布。每次发布看起来只是一个个的容器程序,实则不然,其实是一组组一批批的容器,只有帮客户做到批量的应用发布,才能显著提升发布效率。


蓝绿部署方面,该银行密集的线上营销中,每一天会有一个重点营销活动,那么营销活动的流量如何分到特别的人群、区域?在后台应用的上千个实例中,并不是每一个实例都分配同等的流量,要通过流量分发,做线上流量控制。数人云借鉴Google做灰度发布的方式为客户提供图形化的流量控制,这和微服务实施后的限流分流是息息相关的。

另外,该银行客户的数据流量非常大,对日志收集带来非常大的的压力。数人云建议客户将应用程序的日志全部交给Kafka采集,Kafka可以做到很大数据流量的分布式消息应用。


分布式数据传输分布式消息应用很难保证每一个消息都可靠地传递。Kafka有两种模式:一种保证消息传递至少一次,但也可能多次,对很大的日志量来说偶尔丢一两条可以忽略不计。Kafka的并发量很大,可能带来偶尔很小的数据量丢失,也可能带来日志的乱序,这在分布式系统下都是可以容忍的,“鱼和熊掌不可兼得”。


关于快速建立支撑微服务体系,数人云有几点总结:
1.开发框架不能用重量级的应用体系,要么是轻量化单体架构的Tomcat等,要么采用Spring Cloud等微服务架构。

2.要有微服务平台,具备快速配置管理能力、部署能力、监控能力、应用管理能力等配套管理能力。很多企业的痛点是,开发人员快速学习微服务开发技术,基于Spring Cloud做业务系统后,业务系统无法上线,因为运维部门缺乏配套的工具、平台支撑微服务线上运行管理。

3.DevOps融合,平台管理需要把链条全打通,实现快速发布、快速上线、自动修复等。容器经过几年的普及企业已经相对了解,但容器本身是纯技术平台,基于容器、DevOps的落地还有很长的路要走。>>>>数人云微服务On PaaS 产品体系


数人云现在的重点是微服务、轻量单体应用。以前数人云帮企业客户落地重应用的容器平台,但后来发现价值不大,反而对企业来说,除了维护重的应用外还需要维护容器,容器平台并不能实现自动化运维。经过几年的实践和摸索,数人云跟企业客户达成的共识是,传统应用不经过改造无法上到云PaaS平台。


 轻量架构下的应用如何基于PaaS平台支撑?以敏捷开发为例,企业客户通常选择 Spring Cloud、gRPC 等主流的开发框架,然后在微服务工具链层面配置监控、报警、部署、快速发布等方方面面的能力,最下面承载的则是容器平台。


数人云现在还可以帮助客户落地服务网格化技术。它能够进行异构架构的兼容,gRPC就是服务网格的一部分,Google推的 Istio,Linkerd的Kubernetes 都支持 gRPC,gRPC成为通讯协议的一部分。基于通讯协议相应周边的管理,在服务网格这一层可以做灰度发布、A/B测试、流量控制、高级熔断、加密、白/黑名单机制、权限访问控制等等。


服务网格被称作下一代的微服务,因为用了服务网格以后,所有微服务管理的诉求都自动化地满足了。80%-90%的应用管理需求都在服务网格里自动涵盖。这对开发人员来讲,微服务开发的门槛急剧降低,不需要考虑未来应用上线时流量控制、灰度发布等等,只需要考虑业务。数人云微服务On PaaS 目的就是帮助企业客户降低微服务架构、上云转型的门槛。
 

Q1:感觉对DevOps的理解不太到位,能不能具体地讲一下?A1:DevOps准确来讲,现在业内还没有统一的认识。互联网公司的DevOps目前是比较统一的,比如Goolge,但是互联网公司的DevOps,我个人理解没办法在企业直接落地。


在Google,程序员不止要负责应用的开发,还要负责相应的测试,单元测试、集成测试等等。另外,应用的部署、发布、上线也是开发人员自己做。所以互联网公司讲DevOps,更多讲的是开发运维的融合。我之前在Google时,不仅要做代码开发,也要把测试的代码全写出来。


Google有一个理念,开发人员每写一行业务代码,测试代码要写十行。然后,开发人员利用各种发布平台定期发布,比如每周做发布,在Google 运维的人员叫“SRE”。SRE部门准备好各种平台,开发人员可以用这些平台做发布、监控、日志管理等工作。


Google目前有三万名左右的IT人员,其中SRE的运维人员只有一千多,比例很低。所以在Google运维人员不可能帮每一个开发人员或者业务部门做上线。像传统IT开发人员提工单给运维,在Google是不可能的。Google这种做法,它让开发做更多的事情,运维人员很少,只是负责维护平台。所以,Google一千多人管理着几百万台服务器,平均每人管两千台。


但传统企业目前不是这样,传统企业开发和运维之间壁垒比较大。数人云帮助客户落地DevOps 时,基于的理念是,不要破坏现有开发的流程。DevOps应该是开发和运维深度融合才能做到的。讲DevOps,首先要讲理念、组织的变革,但是要想把文化变革、组织变革打破要很长时间。


从落地的角度,DevOps更多落地在运维部门,很具象的工作就是,帮助运维部门去实现DevOps的能力,比如快速部署、快速上线,应用的快速配置,自动化管理能力、故障的自动化处理等等。把以前的运维工作尽可能的自动化,提高效率,这是狭义的DevOps理念,也是我们现在接触到的。数人云不会帮客户落地像互联网公司那样的DevOps,开发做很多事情,运维可做的很少,并不是这样的。


 Q&A
Q2:微服务适合复杂的场景,那么一个简单的促销是不是适合?微服务有多“微”呢?微服务和ESB 服务相比,有什么差别?A2:第一个促销场景,促销场景本身有些条件,促销很重要一点就是必须特别频繁,促销内容在平台要发生变化。比如,今天的促销内容和明天的不太一样,或者这周的促销和下周的不太一样,业务平台需要频繁变更,这时候微服务是适合的。


因为微服务是一种敏捷开发的落地实践方法,只要业务频繁变更,对开发的要求就必须敏捷开发,快速实现。所以,只要业务场景在不停地快速变化,促销又是互联网线上的方式,肯定是适合的。

 
关于复杂性,如果业务逻辑简单,逻辑变化少,并不适合微服务。比如数人云和很多银行客户合作,银行核心系统很复杂,但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”,就是银行核心系统的功能越来越单一,越来越瘦,并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂,但业务不会频繁变化,也不一定要上到微服务场景下。复杂的业务系统,业务需求又不停变化,这种场景适合微服务。


第二个问题是和ESB 比,服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来,很多不同的业务系统都上到ESB,互相的权限通过ESB打通。从功能角度讲,ESB和服务网格之间很相像,不同点在于ESB是传统架构下的,并没有考虑频繁迭代、流量集中爆发等问题。


但是微服务情况下,整个之间的互相请求、依赖、通讯等等都会进行统一的管理,这种情况下也很像ESB把不同业务之间的流量进行统一管理,但是服务网格更看重的是面向大规模的控制,那流量突发怎么做限流,或者突然故障怎么做熔断等等。最本质的问题是类似的,但是具体的问题表象和需求不同。 Q&A 
Q3:在实际部署过程中,PaaS平台在底层资源的调用一定要用分布式云架构,传统主机是否可以?两者在最后效果上有没有什么异同?A3:数人云当初两种情况都有,有些场景比如业务量比较大,企业客户为了减少复杂度,容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理,把PaaS落地到IaaS上,两种情况都有。


这其中的考虑是,首先业务量大如果再引入虚拟化这一层会引来额外的复杂度,此时用物理服务器更好。其次,客户有很大规模的物理服务器,直接在上面部署PaaS,在物理服务器上去调用。

 
第三种,资源动态的调整或资源频繁调配,这个场景很常见,需要IaaS。比如银行客户,内部业务系统分不同的域,不同域的业务复杂性随时间变化经常会发生变化,需要不停地做资源动态的调整。如果用物理机太麻烦,企业客户会选择下面有一层IaaS来做。


基于PaaS也能做一部分的资源动态调配,但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度,PaaS平台是按照应用程序来划分,IaaS的资源划分是按照业务系统。


 Q&A 
Q4:微服务重新开发,最佳的开发框架或者实践有什么可以分享的?第二,旧有的系统改造到微服务这块有没有什么经验?第三,DevOps以前也有很多像敏捷开发的方法论,它们之间有没有什么关系?A4:首先第一个问题,微服务的开发框架。企业客户在做选择时都希望降低风险,选最主流的框架,现在看最主流的开发框架就是Spring cloud,这也是业界的自然选择结果。其他语言也都有些微服务开发,但是用的人少一些。如果是Java应用,目前比较好的选择是Spring Cloud,也有很多客户用了Dubbo,其他架构都是偏小众的架构,主要还是看客户自己的需求。


第二个问题,传统业务要转到微服务架构上,一定要循序渐进。比如Java应用,首先Java中间件的应用,先脱掉,不要再基于这么重的Java中间件。目前相对流行的是Spring Boot这套逻辑。


有了轻量的单体化应用之后(基于Tomcat),往后走基于微服务的框架,上到Spring Boot,再上到Spring Cloud,这是比较平滑的方式。Spring Boot 在很企业客户中用的非常多,是很方便的一套单体开发架构。

 
企业客户目前的现状是老的应用很多,不会一次就改造完,传统的应用可以先选择一部分容易转的转到轻量单体架构上,然后再转到微服务框架上。目前企业客户是轻量的单体架构、微服务架构,以及大量传统的架构应用并存。老的架构应用目前上不到PaaS平台,只有轻量的单体化加微服务应用才能上到PaaS平台。



现在业内的共识是,微服务、容器、DevOps这三者是密不可分的。微服务更多是针对开发人员,是一种真正落地的云开发方法。很多企业客户也讲敏捷开发,派团队成员学习敏捷开发的方法论,但是敏捷开发仍然无法在企业当中落地。


这是因为,只学会了方法,但没办法落地到具体的编程,即开发环节上去,自然没办法做到敏捷开发。很多开发者回来写的程序依然是J2EE。J2EE 编程的理念和方法并不是敏捷开发的,是偏向于瀑布式的。

微服务是具体的开发环节上的敏捷开发方法,开发能力化整为零,每个团队做简单、具象、单一的逻辑。微服务首先是一个具像的敏捷开发方法,实践方法。

微服务在落地时,比如程序运行时,复杂度很高,因为不是一个程序,是一批程序一起运行,对运维的管理就比较复杂,这时候可以利用容器实现微服务应用的自动化管理。微服务一般都会上到容器,因为微服务应用不再是单体的部署方式,不再是部署到Java中间件上。基于微服务架构,几百个进程进来,用容器的方式实现快速部署动态调度,微服务部署到容器上,实现基础的轻量化运维。


轻量化运维,快速部署、自动化调度,逐步往DevOps方向走。DevOps更多强调自动化的运维能力,提高运维的效率,快速部署,出了问题自动化修复。需要用到工具和平台,这就是数人云现在帮客户去做的。


把微服务业务在运行时缺失的管理方式方法、工具平台,工具链补齐。首先是配置管理能力、完备的监控能力等等,普及之后运维人员就有能力来管微服务应用。这其实是DevOps里面最狭义的,让运维的能力变得轻量。


如果要真正实现DevOps,就像目前一些互联网公司做到的,开发和运维真正的深度融合在一起。企业目前的运维一般不具有编程能力,所以真正的DevOps还需要很长时间去落地。

 

微服务落地践行渐进,4个Q&A一窥金融微服务现状

杨y 发表了文章 • 0 个评论 • 133 次浏览 • 2018-01-18 00:47 • 来自相关话题

1月13日,中国双态运维用户大会在北京举办。来自银行、保险、证券、政府、央企等多个行业的330多位企业用户参加,其中工商银行信息科技部副总经理张艳,国泰君安信息技术部总经理俞枫、海关总署科技发展司运行安全处处长张芳、平安科技系统运营部总经理陈亚殊等分别发表了演讲。本文为数人云CEO王璞在双态运维用户大会DevOps、容器与微服务分论坛上的演讲实录。演讲结束,与在座金融客户展开了精彩的Q&A分享。

容器、微服务、DevOps三者,业内的共识是密不可分。没有微服务,DevOps落地不下去,没有容器,DevOps也无法真正实现敏捷运维、自动化运维。DevOps、容器、微服务为更好的构建PaaS提供了方法论和技术手段。

1、PaaS之承上启下

PaaS作为云计算的承上启下要素,向上支撑各环境应用,向下跟IaaS、计算环境、计算资源对接,是企业云化的必由之路。>>>>PaaS三大技术趋势

1.应用容器化,容器正在成为云计算原生应用的标准交付方式。

2.微服务网格化,随着企业对微服务的认知越来越深入,下一代微服务着重把应用管理作为核心。因为企业应用一定要有很强的管理在微服务架构上,不能让应用去“裸奔”。数人云没有提微服务化,因为微服务化已经是不争的事实。应用微服务缺乏强大的管理,需要服务网格这样的下一代微服务技术。

3.行业生态化,PaaS技术本质上是支持应用的,应用跟业务紧密结合,所以PaaS最终是要和业务层面融合,行业需要生态化。>>>>PaaS落地三大要素:

PaaS要在企业客户方面落地不可或缺三要素:规模化、统一化、标准化。企业客户落地云计算平台、技术,本质上是希望提高效率,对业务有更好的敏捷支撑。

所有应用,比如容器应用、微服务应用,都实现标准化。标准化以后进行统一化管理,包括部署、发布、故障恢复、监控告警等都实现统一化管理。最后实现模块化,整个系统都是轻量的,微小模块化的。只有基于这三点的PaaS平台和云计算平台,才能够让IT系统真正实现敏捷轻量,提高IT对业务支撑的效果。

2、企业IT架构转型之开发&运维

企业客户目前在架构转型应用中面临的现状是,企业里大量传统应用,客户希望先实现轻量的单体架构,即摆脱很多中间件,摆脱外部服务,MVC架构、单体复杂架构等首先实现轻量化。

数人云日常接触的客户中,走的比较靠前的客户已经在用Spring Cloud、Dubbo等架构,部分客户相当数量的应用已经微服务化,不过处于中间状态,正在考虑评估微服务架构的客户比例还是最大。总之,企业目前的现状是为服务应用、轻量单体应用,以及传统的巨石应用并存。

在架构转型过程中,正确和常态的路径一定是一步步走过来,而不是传统架构丢掉直接上微服务。>>>>DevOps和容器@轻量单体应用架构

在单体应用架构下,DevOps、容器帮助企业实现敏捷IT。首先,持续集成持续交付CI/CD,只要应用是相对轻量的,就能加快中间件应用。CI/CD其中重要的一点是变更发布管理。


数人云某客户上了容器的应用都是轻量化的,基于 Tomcat 和微服务的应用。当基于容器实现快速发布以后,企业发现,所有发布里有一半的发布失败是由于配置不正确引起的。所以,如果没有发布变更管理,发布失败的中间环节有方方面面的因素。

当基于容器实现快速发布之后,容器对环境的异构做了一层屏蔽,这时如果出现处理的问题就是配置管理的问题了,由于涉及不同的环境和应用,配置环境变成应用发布很容易出错的环节。>>>>DevOps和容器@微服务应用架构

数人云做了企业客户微服务落地状况的调研(微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑),在报告中,有15%左右的企业引入了Spring Cloud、Dubbo。微服务在企业里首当其冲的是敏捷开发,因为微服务是一种切实的敏捷开发的方法。


敏捷开发在IT界已经推广多年,但很多时候敏捷开发推的都是方法论,比如Scrum。微服务是一套切实能够落地到IT人员、开发人员开发过程中的实践方法,这是微服务首当其冲的好处,很多企业的开发部门对微服务非常欢迎。不过,15%还是偏小的一个采用比例,微服务还不是企业客户主流的IT架构。

开发人员都比较欢迎微服务,因为能够提升开发效率,落地敏捷开发,但微服务的阻碍还是不小的,微服务对开发运维来说,带来的复杂度急剧上升。传统运维管理的服务器数量、应用数量有限。企业决定采用微服务本身就表明业务很复杂,单体应用做传统的瀑布式开发效率太低,微服务将应用拆分成较小的模块,因此微服务应用一旦上线,程序的数量呈现爆炸式增长。


例如,数人云某个传统企业的客户,目前部署了微服务相关的应用,基于Spring Cloud、Spring Boot,跑在几千个容器上,几千个容器如果通过传统运维方式去管理的话几乎是不可能的。这就是很多微服务无法落地的原因——很多企业客户缺乏相应的运维能力,没有相应的平台、工具、方式、方法管理微服务应用。
 
>>>>微服务落地的必要条件


微服务应用落地,首当其冲是配套工具链的完善。开发人员采用微服务的影响相对改变小一些。采用SpringCloud或者Dubbo、gRPC等,只是开发框架上的并更。其他开发流程如代码托管、代码审查、测试等并不涉及,所以开发流程相对简单。但微服务对运维功能的要求就会复杂,相应的快速配置能力、完备的监控能力、快速部署能力等对传统运维来说都是缺失的,容器能够补足这方面的能力,让运维部门具有DevOps的能力。

关于微服务的拆分,其实是业务部门需要真正解决的问题。微服务对组织上也有变更,将团队化整为零。通常每个单独的微服务程序都由7-10人的小团队来负责维护,这些都是微服务落地的必要条件。
 
对于数人云来说,直接能够给客户提供的帮助,首先是工具链方面,数人云产品层面具备丰富的微服务配套工具链,从监控、日志、调度、故障自动化修复等等都有完备的工具链。在落地方法上,数人云搭建了自己的生态圈,和很多合作伙伴合作,例如跟埃森哲公司在合作,帮助企业客户落地微服务,进行业务的梳理。
 
>>>>容器和微服务共生


容器技术补齐了微服务相关的工具链,对企业全面向云计算转型提供了很大帮助。应用架构是微服务分布式的,相应的运维也要有自动化、敏捷运维的能力。微服务跑在容器上才能发挥它最好的特性。容器是目前最流行的应用环境,基于容器的微服务部署和更新更快,更轻量,服务之间的调用、服务发现、负载均衡等更灵活。


不过,微服务不是万能的。简单的业务场景单体应用其实足够,微服务一定是应用在复杂的业务场景下,只有复杂的业务场景才有很大的维护成本、维护压力,微服务是用来降低复杂业务场景的维护成本。>>>>基于容器云的微服务运行时管理体系

一个完整的微服务管理体系,除了开发框架之外,对运维部门来说,运维微服务应用最基本的路由、负载均衡等功能,容器可以提供,不过容器提供的只是一部分跟微服务相关的能力和工具链。周围还有一大批需要配套的工具,比如配置管理、API网关、注册发现、应用监控等等。这里的监控不是容器CPU内存的监控,而是业务逻辑的监控,更准确一点是全链路跟踪的全链路监控。容器满足了微服务运行时管理的需求,不过周边许多权限、网关、配置等尚无余力满足。

>>>>统一配置中心是微服务体系的核心

统一配置管理,是微服务落地时很核心的点。要在平台工具上落地微服务首先要具备快速配置能力,因为客户采用微服务和容器平台以后,很快会发现50%以上的发布失败是因为配置没搞对,因此配置管理是微服务里首当其冲的问题。

因为每个企业客户都有开发环境、测试环境、生产环境等很多环境,同一个应用不同版本在不同环境下的配置不同。几何级数的配置项、配置元素的增长会导致配置管理的复杂度急剧上升,需要统一的配置中心进行管理。数人云在帮助企业客户落地微服务时,首先会做的是把配置搞定,没有灵活快速的配置管理能力,微服务运行不起来。
 
>>>>变更发布管理(灰度发布 v.s. 蓝绿部署)

在发布管理方面,数人云帮助企业落地的发布管理主要是蓝绿部署,因为很多企业的应用本身不支持灰度发布。蓝绿部署也是切切实实的快速发布,发布用变更窗口的方式来实现。

例如,周五晚上12点起进行发布变更,12点就要停服务中心。蓝绿部署可以显著地缩短服务不可用的变更窗口。怎么做呢?客户在线上有两个版本,蓝版本和绿版本。现在负载均衡器将流量指向对外提供服务的绿版本,蓝版本作为备用的方案。同时,新程序往蓝版本上部署推送,更新时只需要把流量切换到蓝版本。发布流程最后简化为只需要进行流量的切换。流量可以快速切换,中间的窗口期只有短短几分钟,如果流量切换过来一切正常发布即完成,如果流量切换过来发现问题,可以再将流量切回去。这样开发人员、运维人员不必当场熬夜去修复,极大地减轻了发布的压力。

传统发布方式下,每次变更窗口有好几个应用排队发布,一个应用发布完成后才可以发布下一个应用,一旦中间某一个应用发布失败现场修复的压力非常大,短短的发布窗口需要几个小时内完成抢修,非常不可控,团队经常需要晚上熬夜排队。而结果往往等了半天,前面的应用没发布成功,后面的还得继续排队等。

3、金融行业之践行渐进

数人云在金融、能源、制造、快消、政企等行业的基础上,继续深耕强监管、强安全,高复杂度的金融行业。以某商业银行为例,数人云帮助落地了大规模微服务容器平台。该商业银行近年来互联网业务发展迅猛,原有系统架构无法支撑其未来规划。2016年6月开始全面实施应用微服务化,已实现蓝绿发布。


首先,营销系统全部是轻量化的应用,基于Spring Boot、Tomcat、SpringCloud等,跑在容器平台上。该银行对外营销频次非常高,通过线上微信公众号、手机APP、线上门户、合作伙伴等渠道,每月对外营销达上百场。

每次营销活动或多或少都对IT系统有变更,哪怕是配置变更,因此每次营销活动对IT系统都是一次不小的挑战。发布的时候仅仅靠容器是不够的,需要实现模板的批量发布。每次发布看起来只是一个个的容器程序,实则不然,其实是一组组一批批的容器,只有帮客户做到批量的应用发布,才能显著提升发布效率。

蓝绿部署方面,该银行密集的线上营销中,每一天会有一个重点营销活动,那么营销活动的流量如何分到特别的人群、区域?在后台应用的上千个实例中,并不是每一个实例都分配同等的流量,要通过流量分发,做线上流量控制。数人云借鉴Google做灰度发布的方式为客户提供图形化的流量控制,这和微服务实施后的限流分流是息息相关的。

另外,该银行客户的数据流量非常大,对日志收集带来非常大的的压力。数人云建议客户将应用程序的日志全部交给Kafka采集,Kafka可以做到很大数据流量的分布式消息应用。

分布式数据传输分布式消息应用很难保证每一个消息都可靠地传递。Kafka有两种模式:一种保证消息传递至少一次,但也可能多次,对很大的日志量来说偶尔丢一两条可以忽略不计。Kafka的并发量很大,可能带来偶尔很小的数据量丢失,也可能带来日志的乱序,这在分布式系统下都是可以容忍的,“鱼和熊掌不可兼得”。

关于快速建立支撑微服务体系,数人云有几点总结:
 
1.开发框架不能用重量级的应用体系,要么是轻量化单体架构的Tomcat等,要么采用Spring Cloud等微服务架构。

2.要有微服务平台,具备快速配置管理能力、部署能力、监控能力、应用管理能力等配套管理能力。很多企业的痛点是,开发人员快速学习微服务开发技术,基于Spring Cloud做业务系统后,业务系统无法上线,因为运维部门缺乏配套的工具、平台支撑微服务线上运行管理。

3.DevOps融合,平台管理需要把链条全打通,实现快速发布、快速上线、自动修复等。容器经过几年的普及企业已经相对了解,但容器本身是纯技术平台,基于容器、DevOps的落地还有很长的路要走。>>>>数人云微服务On PaaS 产品体系


数人云现在的重点是微服务、轻量单体应用。以前数人云帮企业客户落地重应用的容器平台,但后来发现价值不大,反而对企业来说,除了维护重的应用外还需要维护容器,容器平台并不能实现自动化运维。经过几年的实践和摸索,数人云跟企业客户达成的共识是,传统应用不经过改造无法上到云PaaS平台。

 轻量架构下的应用如何基于PaaS平台支撑?以敏捷开发为例,企业客户通常选择 Spring Cloud、gRPC 等主流的开发框架,然后在微服务工具链层面配置监控、报警、部署、快速发布等方方面面的能力,最下面承载的则是容器平台。


数人云现在还可以帮助客户落地服务网格化技术。它能够进行异构架构的兼容,gRPC就是服务网格的一部分,Google推的 Istio,Linkerd的Kubernetes 都支持 gRPC,gRPC成为通讯协议的一部分。基于通讯协议相应周边的管理,在服务网格这一层可以做灰度发布、A/B测试、流量控制、高级熔断、加密、白/黑名单机制、权限访问控制等等。


服务网格被称作下一代的微服务,因为用了服务网格以后,所有微服务管理的诉求都自动化地满足了。80%-90%的应用管理需求都在服务网格里自动涵盖。这对开发人员来讲,微服务开发的门槛急剧降低,不需要考虑未来应用上线时流量控制、灰度发布等等,只需要考虑业务。数人云微服务On PaaS 目的就是帮助企业客户降低微服务架构、上云转型的门槛。


 Q&A
 
Q1:感觉对DevOps的理解不太到位,能不能具体地讲一下?A1:DevOps准确来讲,现在业内还没有统一的认识。互联网公司的DevOps目前是比较统一的,比如Goolge,但是互联网公司的DevOps,我个人理解没办法在企业直接落地。




在Google,程序员不止要负责应用的开发,还要负责相应的测试,单元测试、集成测试等等。另外,应用的部署、发布、上线也是开发人员自己做。所以互联网公司讲DevOps,更多讲的是开发运维的融合。我之前在Google时,不仅要做代码开发,也要把测试的代码全写出来。

Google有一个理念,开发人员每写一行业务代码,测试代码要写十行。然后,开发人员利用各种发布平台定期发布,比如每周做发布,在Google 运维的人员叫“SRE”。SRE部门准备好各种平台,开发人员可以用这些平台做发布、监控、日志管理等工作。

Google目前有三万名左右的IT人员,其中SRE的运维人员只有一千多,比例很低。所以在Google运维人员不可能帮每一个开发人员或者业务部门做上线。像传统IT开发人员提工单给运维,在Google是不可能的。Google这种做法,它让开发做更多的事情,运维人员很少,只是负责维护平台。所以,Google一千多人管理着几百万台服务器,平均每人管两千台。


但传统企业目前不是这样,传统企业开发和运维之间壁垒比较大。数人云帮助客户落地DevOps 时,基于的理念是,不要破坏现有开发的流程。DevOps应该是开发和运维深度融合才能做到的。讲DevOps,首先要讲理念、组织的变革,但是要想把文化变革、组织变革打破要很长时间。

从落地的角度,DevOps更多落地在运维部门,很具象的工作就是,帮助运维部门去实现DevOps的能力,比如快速部署、快速上线,应用的快速配置,自动化管理能力、故障的自动化处理等等。把以前的运维工作尽可能的自动化,提高效率,这是狭义的DevOps理念,也是我们现在接触到的。数人云不会帮客户落地像互联网公司那样的DevOps,开发做很多事情,运维可做的很少,并不是这样的。

Q2:微服务适合复杂的场景,那么一个简单的促销是不是适合?微服务有多“微”呢?微服务和ESB 服务相比,有什么差别?A2:第一个促销场景,促销场景本身有些条件,促销很重要一点就是必须特别频繁,促销内容在平台要发生变化。比如,今天的促销内容和明天的不太一样,或者这周的促销和下周的不太一样,业务平台需要频繁变更,这时候微服务是适合的。

因为微服务是一种敏捷开发的落地实践方法,只要业务频繁变更,对开发的要求就必须敏捷开发,快速实现。所以,只要业务场景在不停地快速变化,促销又是互联网线上的方式,肯定是适合的。

关于复杂性,如果业务逻辑简单,逻辑变化少,并不适合微服务。比如数人云和很多银行客户合作,银行核心系统很复杂,但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”,就是银行核心系统的功能越来越单一,越来越瘦,并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂,但业务不会频繁变化,也不一定要上到微服务场景下。复杂的业务系统,业务需求又不停变化,这种场景适合微服务。

第二个问题是和ESB 比,服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来,很多不同的业务系统都上到ESB,互相的权限通过ESB打通。从功能角度讲,ESB和服务网格之间很相像,不同点在于ESB是传统架构下的,并没有考虑频繁迭代、流量集中爆发等问题。


但是微服务情况下,整个之间的互相请求、依赖、通讯等等都会进行统一的管理,这种情况下也很像ESB把不同业务之间的流量进行统一管理,但是服务网格更看重的是面向大规模的控制,那流量突发怎么做限流,或者突然故障怎么做熔断等等。最本质的问题是类似的,但是具体的问题表象和需求不同。

Q3:在实际部署过程中,PaaS平台在底层资源的调用一定要用分布式云架构,传统主机是否可以?两者在最后效果上有没有什么异同?A3:数人云当初两种情况都有,有些场景比如业务量比较大,企业客户为了减少复杂度,容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理,把PaaS落地到IaaS上,两种情况都有。

这其中的考虑是,首先业务量大如果再引入虚拟化这一层会引来额外的复杂度,此时用物理服务器更好。其次,客户有很大规模的物理服务器,直接在上面部署PaaS,在物理服务器上去调用。


第三种,资源动态的调整或资源频繁调配,这个场景很常见,需要IaaS。比如银行客户,内部业务系统分不同的域,不同域的业务复杂性随时间变化经常会发生变化,需要不停地做资源动态的调整。如果用物理机太麻烦,企业客户会选择下面有一层IaaS来做。

基于PaaS也能做一部分的资源动态调配,但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度,PaaS平台是按照应用程序来划分,IaaS的资源划分是按照业务系统。

Q4:微服务重新开发,最佳的开发框架或者实践有什么可以分享的?第二,旧有的系统改造到微服务这块有没有什么经验?第三,DevOps以前也有很多像敏捷开发的方法论,它们之间有没有什么关系?A4:首先第一个问题,微服务的开发框架。企业客户在做选择时都希望降低风险,选最主流的框架,现在看最主流的开发框架就是Spring cloud,这也是业界的自然选择结果。其他语言也都有些微服务开发,但是用的人少一些。如果是Java应用,目前比较好的选择是Spring Cloud,也有很多客户用了Dubbo,其他架构都是偏小众的架构,主要还是看客户自己的需求。

第二个问题,传统业务要转到微服务架构上,一定要循序渐进。比如Java应用,首先Java中间件的应用,先脱掉,不要再基于这么重的Java中间件。目前相对流行的是Spring Boot这套逻辑。

有了轻量的单体化应用之后(基于Tomcat),往后走基于微服务的框架,上到Spring Boot,再上到Spring Cloud,这是比较平滑的方式。Spring Boot 在很企业客户中用的非常多,是很方便的一套单体开发架构。

企业客户目前的现状是老的应用很多,不会一次就改造完,传统的应用可以先选择一部分容易转的转到轻量单体架构上,然后再转到微服务框架上。目前企业客户是轻量的单体架构、微服务架构,以及大量传统的架构应用并存。老的架构应用目前上不到PaaS平台,只有轻量的单体化加微服务应用才能上到PaaS平台。

现在业内的共识是,微服务、容器、DevOps这三者是密不可分的。微服务更多是针对开发人员,是一种真正落地的云开发方法。很多企业客户也讲敏捷开发,派团队成员学习敏捷开发的方法论,但是敏捷开发仍然无法在企业当中落地。

这是因为,只学会了方法,但没办法落地到具体的编程,即开发环节上去,自然没办法做到敏捷开发。很多开发者回来写的程序依然是J2EE。J2EE 编程的理念和方法并不是敏捷开发的,是偏向于瀑布式的。

微服务是具体的开发环节上的敏捷开发方法,开发能力化整为零,每个团队做简单、具象、单一的逻辑。微服务首先是一个具像的敏捷开发方法,实践方法。

微服务在落地时,比如程序运行时,复杂度很高,因为不是一个程序,是一批程序一起运行,对运维的管理就比较复杂,这时候可以利用容器实现微服务应用的自动化管理。微服务一般都会上到容器,因为微服务应用不再是单体的部署方式,不再是部署到Java中间件上。基于微服务架构,几百个进程进来,用容器的方式实现快速部署动态调度,微服务部署到容器上,实现基础的轻量化运维。


轻量化运维,快速部署、自动化调度,逐步往DevOps方向走。DevOps更多强调自动化的运维能力,提高运维的效率,快速部署,出了问题自动化修复。需要用到工具和平台,这就是数人云现在帮客户去做的。


把微服务业务在运行时缺失的管理方式方法、工具平台,工具链补齐。首先是配置管理能力、完备的监控能力等等,普及之后运维人员就有能力来管微服务应用。这其实是DevOps里面最狭义的,让运维的能力变得轻量。


如果要真正实现DevOps,就像目前一些互联网公司做到的,开发和运维真正的深度融合在一起。企业目前的运维一般不具有编程能力,所以真正的DevOps还需要很长时间去落地。 查看全部

1月13日,中国双态运维用户大会在北京举办。来自银行、保险、证券、政府、央企等多个行业的330多位企业用户参加,其中工商银行信息科技部副总经理张艳,国泰君安信息技术部总经理俞枫、海关总署科技发展司运行安全处处长张芳、平安科技系统运营部总经理陈亚殊等分别发表了演讲。本文为数人云CEO王璞在双态运维用户大会DevOps、容器与微服务分论坛上的演讲实录。演讲结束,与在座金融客户展开了精彩的Q&A分享。

容器、微服务、DevOps三者,业内的共识是密不可分。没有微服务,DevOps落地不下去,没有容器,DevOps也无法真正实现敏捷运维、自动化运维。DevOps、容器、微服务为更好的构建PaaS提供了方法论和技术手段。

1、PaaS之承上启下

PaaS作为云计算的承上启下要素,向上支撑各环境应用,向下跟IaaS、计算环境、计算资源对接,是企业云化的必由之路。>>>>PaaS三大技术趋势

1.应用容器化,容器正在成为云计算原生应用的标准交付方式。

2.微服务网格化,随着企业对微服务的认知越来越深入,下一代微服务着重把应用管理作为核心。因为企业应用一定要有很强的管理在微服务架构上,不能让应用去“裸奔”。数人云没有提微服务化,因为微服务化已经是不争的事实。应用微服务缺乏强大的管理,需要服务网格这样的下一代微服务技术。

3.行业生态化,PaaS技术本质上是支持应用的,应用跟业务紧密结合,所以PaaS最终是要和业务层面融合,行业需要生态化。>>>>PaaS落地三大要素:

PaaS要在企业客户方面落地不可或缺三要素:规模化、统一化、标准化。企业客户落地云计算平台、技术,本质上是希望提高效率,对业务有更好的敏捷支撑。

所有应用,比如容器应用、微服务应用,都实现标准化。标准化以后进行统一化管理,包括部署、发布、故障恢复、监控告警等都实现统一化管理。最后实现模块化,整个系统都是轻量的,微小模块化的。只有基于这三点的PaaS平台和云计算平台,才能够让IT系统真正实现敏捷轻量,提高IT对业务支撑的效果。

2、企业IT架构转型之开发&运维

企业客户目前在架构转型应用中面临的现状是,企业里大量传统应用,客户希望先实现轻量的单体架构,即摆脱很多中间件,摆脱外部服务,MVC架构、单体复杂架构等首先实现轻量化。

数人云日常接触的客户中,走的比较靠前的客户已经在用Spring Cloud、Dubbo等架构,部分客户相当数量的应用已经微服务化,不过处于中间状态,正在考虑评估微服务架构的客户比例还是最大。总之,企业目前的现状是为服务应用、轻量单体应用,以及传统的巨石应用并存。

在架构转型过程中,正确和常态的路径一定是一步步走过来,而不是传统架构丢掉直接上微服务。>>>>DevOps和容器@轻量单体应用架构

在单体应用架构下,DevOps、容器帮助企业实现敏捷IT。首先,持续集成持续交付CI/CD,只要应用是相对轻量的,就能加快中间件应用。CI/CD其中重要的一点是变更发布管理。


数人云某客户上了容器的应用都是轻量化的,基于 Tomcat 和微服务的应用。当基于容器实现快速发布以后,企业发现,所有发布里有一半的发布失败是由于配置不正确引起的。所以,如果没有发布变更管理,发布失败的中间环节有方方面面的因素。

当基于容器实现快速发布之后,容器对环境的异构做了一层屏蔽,这时如果出现处理的问题就是配置管理的问题了,由于涉及不同的环境和应用,配置环境变成应用发布很容易出错的环节。>>>>DevOps和容器@微服务应用架构

数人云做了企业客户微服务落地状况的调研(微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑),在报告中,有15%左右的企业引入了Spring Cloud、Dubbo。微服务在企业里首当其冲的是敏捷开发,因为微服务是一种切实的敏捷开发的方法。


敏捷开发在IT界已经推广多年,但很多时候敏捷开发推的都是方法论,比如Scrum。微服务是一套切实能够落地到IT人员、开发人员开发过程中的实践方法,这是微服务首当其冲的好处,很多企业的开发部门对微服务非常欢迎。不过,15%还是偏小的一个采用比例,微服务还不是企业客户主流的IT架构。

开发人员都比较欢迎微服务,因为能够提升开发效率,落地敏捷开发,但微服务的阻碍还是不小的,微服务对开发运维来说,带来的复杂度急剧上升。传统运维管理的服务器数量、应用数量有限。企业决定采用微服务本身就表明业务很复杂,单体应用做传统的瀑布式开发效率太低,微服务将应用拆分成较小的模块,因此微服务应用一旦上线,程序的数量呈现爆炸式增长。


例如,数人云某个传统企业的客户,目前部署了微服务相关的应用,基于Spring Cloud、Spring Boot,跑在几千个容器上,几千个容器如果通过传统运维方式去管理的话几乎是不可能的。这就是很多微服务无法落地的原因——很多企业客户缺乏相应的运维能力,没有相应的平台、工具、方式、方法管理微服务应用。
 
>>>>微服务落地的必要条件


微服务应用落地,首当其冲是配套工具链的完善。开发人员采用微服务的影响相对改变小一些。采用SpringCloud或者Dubbo、gRPC等,只是开发框架上的并更。其他开发流程如代码托管、代码审查、测试等并不涉及,所以开发流程相对简单。但微服务对运维功能的要求就会复杂,相应的快速配置能力、完备的监控能力、快速部署能力等对传统运维来说都是缺失的,容器能够补足这方面的能力,让运维部门具有DevOps的能力。

关于微服务的拆分,其实是业务部门需要真正解决的问题。微服务对组织上也有变更,将团队化整为零。通常每个单独的微服务程序都由7-10人的小团队来负责维护,这些都是微服务落地的必要条件。
 
对于数人云来说,直接能够给客户提供的帮助,首先是工具链方面,数人云产品层面具备丰富的微服务配套工具链,从监控、日志、调度、故障自动化修复等等都有完备的工具链。在落地方法上,数人云搭建了自己的生态圈,和很多合作伙伴合作,例如跟埃森哲公司在合作,帮助企业客户落地微服务,进行业务的梳理。
 
>>>>容器和微服务共生


容器技术补齐了微服务相关的工具链,对企业全面向云计算转型提供了很大帮助。应用架构是微服务分布式的,相应的运维也要有自动化、敏捷运维的能力。微服务跑在容器上才能发挥它最好的特性。容器是目前最流行的应用环境,基于容器的微服务部署和更新更快,更轻量,服务之间的调用、服务发现、负载均衡等更灵活。


不过,微服务不是万能的。简单的业务场景单体应用其实足够,微服务一定是应用在复杂的业务场景下,只有复杂的业务场景才有很大的维护成本、维护压力,微服务是用来降低复杂业务场景的维护成本。>>>>基于容器云的微服务运行时管理体系

一个完整的微服务管理体系,除了开发框架之外,对运维部门来说,运维微服务应用最基本的路由、负载均衡等功能,容器可以提供,不过容器提供的只是一部分跟微服务相关的能力和工具链。周围还有一大批需要配套的工具,比如配置管理、API网关、注册发现、应用监控等等。这里的监控不是容器CPU内存的监控,而是业务逻辑的监控,更准确一点是全链路跟踪的全链路监控。容器满足了微服务运行时管理的需求,不过周边许多权限、网关、配置等尚无余力满足。

>>>>统一配置中心是微服务体系的核心

统一配置管理,是微服务落地时很核心的点。要在平台工具上落地微服务首先要具备快速配置能力,因为客户采用微服务和容器平台以后,很快会发现50%以上的发布失败是因为配置没搞对,因此配置管理是微服务里首当其冲的问题。

因为每个企业客户都有开发环境、测试环境、生产环境等很多环境,同一个应用不同版本在不同环境下的配置不同。几何级数的配置项、配置元素的增长会导致配置管理的复杂度急剧上升,需要统一的配置中心进行管理。数人云在帮助企业客户落地微服务时,首先会做的是把配置搞定,没有灵活快速的配置管理能力,微服务运行不起来。
 
>>>>变更发布管理(灰度发布 v.s. 蓝绿部署)

在发布管理方面,数人云帮助企业落地的发布管理主要是蓝绿部署,因为很多企业的应用本身不支持灰度发布。蓝绿部署也是切切实实的快速发布,发布用变更窗口的方式来实现。

例如,周五晚上12点起进行发布变更,12点就要停服务中心。蓝绿部署可以显著地缩短服务不可用的变更窗口。怎么做呢?客户在线上有两个版本,蓝版本和绿版本。现在负载均衡器将流量指向对外提供服务的绿版本,蓝版本作为备用的方案。同时,新程序往蓝版本上部署推送,更新时只需要把流量切换到蓝版本。发布流程最后简化为只需要进行流量的切换。流量可以快速切换,中间的窗口期只有短短几分钟,如果流量切换过来一切正常发布即完成,如果流量切换过来发现问题,可以再将流量切回去。这样开发人员、运维人员不必当场熬夜去修复,极大地减轻了发布的压力。

传统发布方式下,每次变更窗口有好几个应用排队发布,一个应用发布完成后才可以发布下一个应用,一旦中间某一个应用发布失败现场修复的压力非常大,短短的发布窗口需要几个小时内完成抢修,非常不可控,团队经常需要晚上熬夜排队。而结果往往等了半天,前面的应用没发布成功,后面的还得继续排队等。

3、金融行业之践行渐进

数人云在金融、能源、制造、快消、政企等行业的基础上,继续深耕强监管、强安全,高复杂度的金融行业。以某商业银行为例,数人云帮助落地了大规模微服务容器平台。该商业银行近年来互联网业务发展迅猛,原有系统架构无法支撑其未来规划。2016年6月开始全面实施应用微服务化,已实现蓝绿发布。


首先,营销系统全部是轻量化的应用,基于Spring Boot、Tomcat、SpringCloud等,跑在容器平台上。该银行对外营销频次非常高,通过线上微信公众号、手机APP、线上门户、合作伙伴等渠道,每月对外营销达上百场。

每次营销活动或多或少都对IT系统有变更,哪怕是配置变更,因此每次营销活动对IT系统都是一次不小的挑战。发布的时候仅仅靠容器是不够的,需要实现模板的批量发布。每次发布看起来只是一个个的容器程序,实则不然,其实是一组组一批批的容器,只有帮客户做到批量的应用发布,才能显著提升发布效率。

蓝绿部署方面,该银行密集的线上营销中,每一天会有一个重点营销活动,那么营销活动的流量如何分到特别的人群、区域?在后台应用的上千个实例中,并不是每一个实例都分配同等的流量,要通过流量分发,做线上流量控制。数人云借鉴Google做灰度发布的方式为客户提供图形化的流量控制,这和微服务实施后的限流分流是息息相关的。

另外,该银行客户的数据流量非常大,对日志收集带来非常大的的压力。数人云建议客户将应用程序的日志全部交给Kafka采集,Kafka可以做到很大数据流量的分布式消息应用。

分布式数据传输分布式消息应用很难保证每一个消息都可靠地传递。Kafka有两种模式:一种保证消息传递至少一次,但也可能多次,对很大的日志量来说偶尔丢一两条可以忽略不计。Kafka的并发量很大,可能带来偶尔很小的数据量丢失,也可能带来日志的乱序,这在分布式系统下都是可以容忍的,“鱼和熊掌不可兼得”。

关于快速建立支撑微服务体系,数人云有几点总结:
 
1.开发框架不能用重量级的应用体系,要么是轻量化单体架构的Tomcat等,要么采用Spring Cloud等微服务架构。

2.要有微服务平台,具备快速配置管理能力、部署能力、监控能力、应用管理能力等配套管理能力。很多企业的痛点是,开发人员快速学习微服务开发技术,基于Spring Cloud做业务系统后,业务系统无法上线,因为运维部门缺乏配套的工具、平台支撑微服务线上运行管理。

3.DevOps融合,平台管理需要把链条全打通,实现快速发布、快速上线、自动修复等。容器经过几年的普及企业已经相对了解,但容器本身是纯技术平台,基于容器、DevOps的落地还有很长的路要走。>>>>数人云微服务On PaaS 产品体系


数人云现在的重点是微服务、轻量单体应用。以前数人云帮企业客户落地重应用的容器平台,但后来发现价值不大,反而对企业来说,除了维护重的应用外还需要维护容器,容器平台并不能实现自动化运维。经过几年的实践和摸索,数人云跟企业客户达成的共识是,传统应用不经过改造无法上到云PaaS平台。

 轻量架构下的应用如何基于PaaS平台支撑?以敏捷开发为例,企业客户通常选择 Spring Cloud、gRPC 等主流的开发框架,然后在微服务工具链层面配置监控、报警、部署、快速发布等方方面面的能力,最下面承载的则是容器平台。


数人云现在还可以帮助客户落地服务网格化技术。它能够进行异构架构的兼容,gRPC就是服务网格的一部分,Google推的 Istio,Linkerd的Kubernetes 都支持 gRPC,gRPC成为通讯协议的一部分。基于通讯协议相应周边的管理,在服务网格这一层可以做灰度发布、A/B测试、流量控制、高级熔断、加密、白/黑名单机制、权限访问控制等等。


服务网格被称作下一代的微服务,因为用了服务网格以后,所有微服务管理的诉求都自动化地满足了。80%-90%的应用管理需求都在服务网格里自动涵盖。这对开发人员来讲,微服务开发的门槛急剧降低,不需要考虑未来应用上线时流量控制、灰度发布等等,只需要考虑业务。数人云微服务On PaaS 目的就是帮助企业客户降低微服务架构、上云转型的门槛。


 Q&A
 
Q1:感觉对DevOps的理解不太到位,能不能具体地讲一下?A1:DevOps准确来讲,现在业内还没有统一的认识。互联网公司的DevOps目前是比较统一的,比如Goolge,但是互联网公司的DevOps,我个人理解没办法在企业直接落地。




在Google,程序员不止要负责应用的开发,还要负责相应的测试,单元测试、集成测试等等。另外,应用的部署、发布、上线也是开发人员自己做。所以互联网公司讲DevOps,更多讲的是开发运维的融合。我之前在Google时,不仅要做代码开发,也要把测试的代码全写出来。

Google有一个理念,开发人员每写一行业务代码,测试代码要写十行。然后,开发人员利用各种发布平台定期发布,比如每周做发布,在Google 运维的人员叫“SRE”。SRE部门准备好各种平台,开发人员可以用这些平台做发布、监控、日志管理等工作。

Google目前有三万名左右的IT人员,其中SRE的运维人员只有一千多,比例很低。所以在Google运维人员不可能帮每一个开发人员或者业务部门做上线。像传统IT开发人员提工单给运维,在Google是不可能的。Google这种做法,它让开发做更多的事情,运维人员很少,只是负责维护平台。所以,Google一千多人管理着几百万台服务器,平均每人管两千台。


但传统企业目前不是这样,传统企业开发和运维之间壁垒比较大。数人云帮助客户落地DevOps 时,基于的理念是,不要破坏现有开发的流程。DevOps应该是开发和运维深度融合才能做到的。讲DevOps,首先要讲理念、组织的变革,但是要想把文化变革、组织变革打破要很长时间。

从落地的角度,DevOps更多落地在运维部门,很具象的工作就是,帮助运维部门去实现DevOps的能力,比如快速部署、快速上线,应用的快速配置,自动化管理能力、故障的自动化处理等等。把以前的运维工作尽可能的自动化,提高效率,这是狭义的DevOps理念,也是我们现在接触到的。数人云不会帮客户落地像互联网公司那样的DevOps,开发做很多事情,运维可做的很少,并不是这样的。

Q2:微服务适合复杂的场景,那么一个简单的促销是不是适合?微服务有多“微”呢?微服务和ESB 服务相比,有什么差别?A2:第一个促销场景,促销场景本身有些条件,促销很重要一点就是必须特别频繁,促销内容在平台要发生变化。比如,今天的促销内容和明天的不太一样,或者这周的促销和下周的不太一样,业务平台需要频繁变更,这时候微服务是适合的。

因为微服务是一种敏捷开发的落地实践方法,只要业务频繁变更,对开发的要求就必须敏捷开发,快速实现。所以,只要业务场景在不停地快速变化,促销又是互联网线上的方式,肯定是适合的。

关于复杂性,如果业务逻辑简单,逻辑变化少,并不适合微服务。比如数人云和很多银行客户合作,银行核心系统很复杂,但是银行系统并不是需求频繁变化的场景。很多银行在做“瘦核心系统”,就是银行核心系统的功能越来越单一,越来越瘦,并不是把复杂的周边的业务也放到银行核心系统里。银行核心系统虽然复杂,但业务不会频繁变化,也不一定要上到微服务场景下。复杂的业务系统,业务需求又不停变化,这种场景适合微服务。

第二个问题是和ESB 比,服务网格和 ESB 有很多相像的地方。ESB有业务逻辑串起来,很多不同的业务系统都上到ESB,互相的权限通过ESB打通。从功能角度讲,ESB和服务网格之间很相像,不同点在于ESB是传统架构下的,并没有考虑频繁迭代、流量集中爆发等问题。


但是微服务情况下,整个之间的互相请求、依赖、通讯等等都会进行统一的管理,这种情况下也很像ESB把不同业务之间的流量进行统一管理,但是服务网格更看重的是面向大规模的控制,那流量突发怎么做限流,或者突然故障怎么做熔断等等。最本质的问题是类似的,但是具体的问题表象和需求不同。

Q3:在实际部署过程中,PaaS平台在底层资源的调用一定要用分布式云架构,传统主机是否可以?两者在最后效果上有没有什么异同?A3:数人云当初两种情况都有,有些场景比如业务量比较大,企业客户为了减少复杂度,容器PaaS平台直接落地到物理服务器上。还有客户为了方便管理,把PaaS落地到IaaS上,两种情况都有。

这其中的考虑是,首先业务量大如果再引入虚拟化这一层会引来额外的复杂度,此时用物理服务器更好。其次,客户有很大规模的物理服务器,直接在上面部署PaaS,在物理服务器上去调用。


第三种,资源动态的调整或资源频繁调配,这个场景很常见,需要IaaS。比如银行客户,内部业务系统分不同的域,不同域的业务复杂性随时间变化经常会发生变化,需要不停地做资源动态的调整。如果用物理机太麻烦,企业客户会选择下面有一层IaaS来做。

基于PaaS也能做一部分的资源动态调配,但是调配维度不同。数人云帮客户落地PaaS时会做资源的整合。从划分的维度,PaaS平台是按照应用程序来划分,IaaS的资源划分是按照业务系统。

Q4:微服务重新开发,最佳的开发框架或者实践有什么可以分享的?第二,旧有的系统改造到微服务这块有没有什么经验?第三,DevOps以前也有很多像敏捷开发的方法论,它们之间有没有什么关系?A4:首先第一个问题,微服务的开发框架。企业客户在做选择时都希望降低风险,选最主流的框架,现在看最主流的开发框架就是Spring cloud,这也是业界的自然选择结果。其他语言也都有些微服务开发,但是用的人少一些。如果是Java应用,目前比较好的选择是Spring Cloud,也有很多客户用了Dubbo,其他架构都是偏小众的架构,主要还是看客户自己的需求。

第二个问题,传统业务要转到微服务架构上,一定要循序渐进。比如Java应用,首先Java中间件的应用,先脱掉,不要再基于这么重的Java中间件。目前相对流行的是Spring Boot这套逻辑。

有了轻量的单体化应用之后(基于Tomcat),往后走基于微服务的框架,上到Spring Boot,再上到Spring Cloud,这是比较平滑的方式。Spring Boot 在很企业客户中用的非常多,是很方便的一套单体开发架构。

企业客户目前的现状是老的应用很多,不会一次就改造完,传统的应用可以先选择一部分容易转的转到轻量单体架构上,然后再转到微服务框架上。目前企业客户是轻量的单体架构、微服务架构,以及大量传统的架构应用并存。老的架构应用目前上不到PaaS平台,只有轻量的单体化加微服务应用才能上到PaaS平台。

现在业内的共识是,微服务、容器、DevOps这三者是密不可分的。微服务更多是针对开发人员,是一种真正落地的云开发方法。很多企业客户也讲敏捷开发,派团队成员学习敏捷开发的方法论,但是敏捷开发仍然无法在企业当中落地。

这是因为,只学会了方法,但没办法落地到具体的编程,即开发环节上去,自然没办法做到敏捷开发。很多开发者回来写的程序依然是J2EE。J2EE 编程的理念和方法并不是敏捷开发的,是偏向于瀑布式的。

微服务是具体的开发环节上的敏捷开发方法,开发能力化整为零,每个团队做简单、具象、单一的逻辑。微服务首先是一个具像的敏捷开发方法,实践方法。

微服务在落地时,比如程序运行时,复杂度很高,因为不是一个程序,是一批程序一起运行,对运维的管理就比较复杂,这时候可以利用容器实现微服务应用的自动化管理。微服务一般都会上到容器,因为微服务应用不再是单体的部署方式,不再是部署到Java中间件上。基于微服务架构,几百个进程进来,用容器的方式实现快速部署动态调度,微服务部署到容器上,实现基础的轻量化运维。


轻量化运维,快速部署、自动化调度,逐步往DevOps方向走。DevOps更多强调自动化的运维能力,提高运维的效率,快速部署,出了问题自动化修复。需要用到工具和平台,这就是数人云现在帮客户去做的。


把微服务业务在运行时缺失的管理方式方法、工具平台,工具链补齐。首先是配置管理能力、完备的监控能力等等,普及之后运维人员就有能力来管微服务应用。这其实是DevOps里面最狭义的,让运维的能力变得轻量。


如果要真正实现DevOps,就像目前一些互联网公司做到的,开发和运维真正的深度融合在一起。企业目前的运维一般不具有编程能力,所以真正的DevOps还需要很长时间去落地。

开发测试一山容得二虎,30条有关测试的故事和事故

杨y 发表了文章 • 0 个评论 • 110 次浏览 • 2018-01-18 00:41 • 来自相关话题

软件工程规则和测试积累的最佳实践,能帮助企业显著节省时间,减少痛点。良好的测试实践既可以确保质量标准,也可以指导和塑造每个程序员的发展。

小数今天推送的这篇文章,文中的许多原则都与测试实践和理想有关,有一些还是Python特有的。正如本文作者所说,程序员的那些固执己见,强烈的意见表达和坚持,往往是激情的最好表现。

1. YAGNI:不要编写现在尚不需要,而将来可能需要的代码。现在的代码不可避免地会变成死代码或需要重写,因为未来的用例总是与设想的不同。如果把代码放在未来的用例中,在代码审查中要提出质疑。(例如,可以并且必须设计API来允许将来的用例,不过,这是另外一个问题。)

注解代码也是如此。如果一个注释代码块进入发行版,它就不应该存在。如果是可以恢复的代码,创建一个ticket,并引用代码删除的提交散列。YAGNI 是敏捷编程的核心元素。Kent Beck提供的极限编程解释(Extreme Programming Explained)就是最好的参考。


2.测试本身不需要测试。用于测试的基础架构,框架和库需要测试。除非确实需要,通常不要测试浏览器或外部库。测试你写的代码,而并非其他人的。

3.第三次编写相同代码时,是将其抽取到通用帮助器(并为其编写测试)的正确时机。测试中的辅助功能不需要测试; 当把它们分解出来并进行重用时,才需要测试。到第三次编写类似的代码时,会清楚地知道正在解决什么样的问题。

4.涉及到API设计:简单的事情简单化; 复杂的事情可能如果可能也简单化。首先设计一个简单的情况,如果可能,最好使用零配置或参数化。为更复杂和更灵活的用例添加选项或其他API方法。


5.快速失败。尽可能早地检查输入,并在无意义的输入或无效状态上失败,使用异常或错误响应,来确定问题。允许代码“创新”,也就是说,通常情况下,不要对输入验证进行类型检查。


6. 单元测试是对行为单元的测试,而不是对实现单元。改变实现,而不是改变行为或被迫改变任何测试,当然这点并不是总能实现。在可能的情况下,将测试对象视为黑盒子,通过公共 API 进行测试,而无需调用私有方法或修改状态。


对于一些复杂的场景,比如一些特定复杂状态下,测试行为找到一个难以理解的错误。编写测试确实有助于解决这个问题,因为它会迫使你在编写代码之前,考虑清楚代码的行为以及如何测试。测试首先鼓励更小,更模块化的代码单元。

7.对于单元测试(包括测试基础结构测试),应该测试所有的代码路径。100%的覆盖率是一个很好的起点。你不能涵盖所有可能的排列/组合状态。在有很好的理由时,代码路径才能被测试。缺少时间不是一个好的理由,这往往导致最终花费更多时间。好的理由包括:真正无法测试,在实践中不可能实现,或者在测试中其他地方被覆盖。没有测试的代码要承担责任。衡量覆盖率,并拒绝降低覆盖率的百分比是朝正确方向前进的一种方法。


8.代码是敌人:可能出错,需要维护。少写代码。删除代码。不要编写你不需要的代码。

9.随着时间的推移,代码注释不可避免地成为谎言。实际上,很少有人在事情发生变化时更新评论。通过良好的命名实践和已知的编程风格,努力使代码有可读性和自我记录。

不明确的代码确实需要注释,比如围绕一个模糊的错误或不可能的条件,或者必要的优化。

10.防守地写。要总是想可能出现什么问题,无效输入会发生什么,什么可能导致失败,这有助于在错误发生前发现错误。

11.如果逻辑无状态且无副作用,则易于进行单元测试。将逻辑分解成独立的函数,而不是混合成有状态和副作用的代码。将有状态和带副作用的代码分离成更小的函数,可以更容易地模拟和单元测试。副作用确实需要测试,测试一次并在其他地方进行模拟,是比较好的做法。

12.Globals are bad。功能优于类型,对象比复杂的数据结构更好。

13.使用 Python 内置类型和方法比编写自己的类型更快(除非用C编写)。如果考虑性能,尝试解决如何使用标准内置类型而不是自定义对象。

14. 依赖注入是一种有用的编程模式,可以清楚了解依赖关系。(让对象,方法等接收依赖关系作为参数,而不是自己实例化新的对象。)这是一种交换,使API签名更加复杂。如果完成依赖项需要使用10个参数,说明代码太多了。


15. 越需要模拟测试代码,它就会越糟糕。需要实例化和放置的代码越多,用来测试特定的行为,代码就越糟糕。测试的目标是小型可测试单元,和更高级别的集成和功能测试,来测试这些单元是否正确地协作。


16.面向外部的 API 是要“预先设计”的,它关系到未来用例。改变 API 对自己和用户来说都是一种痛苦,而创造向后兼容性是非常可怕的,尽管有时不可避免。精心设计面向外部的API,仍然坚持“简单的事情简单化”的原则。


17.如果一个函数或方法超过30行代码,就要考虑分解。好的最大模块大小约为500线。测试文件往往比这个更长。


18.不要在难以测试的对象构造函数中工作。不要把代码放在__init__.py中。程序员不希望在__init__.py找到代码。


19. DRY(Don’t Repeat Yourself不要重复自己)在测试中比在生产中重要得多。单个测试文件的可读性比可维护性更重要(突破可重用的块)。这是因为测试是单独执行和读取的,而不是作为大系统的一部分。过多的重复意味着可重用的组件可以方便地创建,但是与生产相比,测试的重要性低得多。


20.当看到需要并有机会时进行重构。编程是关于抽象的,抽象映射越接近问题域,代码就越容易理解和维护。随着系统有机地增长,需要为扩展用例而改变结构。系统超出抽象和结构,而不改变它们成为技术债务,这会更痛苦,更缓慢,更多bug。包括重构成本,包括对功能的预估。你把债务拖得越久,它积累的利息就越高。Michael Feathers 撰写了一本关于重构和测试的书籍,其中着重介绍了遗留代码。

21.正确的编写代码第一,速度第二。处理性能问题时,请务必在修复之前进行配置。瓶颈通常出乎你的意料。编写难懂的代码如果是为了速度更快,为此你进行了配置并证明这么做是值得的,那么也仅仅是速度上值得而已。编写一个测试,训练正在配置的代码,让它知道什么情况下会变得更简单,并且留在测试套件中,来防止性能下降。(通常情况下,添加计时代码总是会改变代码的性能特点,使性能变得经常差强人意。)


22.更小范围的单元测试在失败时会提供更有价值的信息。要判定错误,有一半的系统测试行为的测试需要依据更多的调查。一般来说,运行时间超过0.1秒的测试不是单元测试。没有所谓的慢单元测试。通过严格范围的单元测试测试行为,你的测试可以作为代码实际规范。理想情况下,如果有人想了解你的代码,应该能够将测试套件作为行为的“文档”。


23. “这里没有发明”并不像人们所说的那么糟糕。如果我们编写代码,我们知道它的作用,知道如何维护它,可以自由地扩展和修改它。这是遵循了YAGNI的原则:我们有需要用例的特定代码,而并非通用代码,通用代码会给我们不需要的部分带来复杂性。另一方面,代码是敌人,拥有更多的代码没有好处,当引入新的依赖关系时需要考虑权衡。


24.共享代码所有权是目标。孤立的知识没什么好,这意味着至少要讨论、记录贯彻设计决策和实施决策。代码审查时开始讨论设计决策是最糟糕,因为在编写代码之后进行彻底的更改太难克服了。当然,在Review时指出和修改设计错误,比永远不总结不思考要好得多。


25.  Generators rock! 与有状态的对象相比,它们用于迭代或重复执行通常更短,更容易理解。


26.让我们成为工程师!设计、建立强大和良好实施的系统,而不是增加有机怪物。编程是一个平衡的行为,我们并不总是建造火箭飞船,过度设计(onion architecture洋葱架构)与设计不足的代码同样令人痛苦。罗伯特•马丁(Robert Martin)所做的几乎任何事情都值得一读,“ 干净架构:软件结构和设计指南”( Clean Architecture: A Craftsman’s Guide to Software Structure and Design )是这方面的好资源。设计模式( Design Patterns)是每个工程师应该阅读的经典编程书籍。


27.间歇性地失败的测试会侵蚀测试套件的价值,以至于最终每个人都忽略测试运行的结果。修复或删除间歇性失败的测试是痛苦的,但值得努力。


28.一般来说,尤其是在测试中,等待一个具体的改变,而不是任意时间内sleeping。Voodoo sleeps 很难理解,而且会放慢测试套件。


29.至少要看到你的测试失败过一次。将一个蓄意的 bug 放入让它失败,或在测试行为完成之前运行测试。否则,你不知道你真的在测试。偶尔写写测试代码实际并不测试任何东西,或写永远不会失败的测试,都是很容易的。


30.最后,管理要点:持续的功能研发是开发软件的一个可怕方法。不让开发人员在工作感到骄傲, 就不会从中获得最大的利益。不解决技术债务,会拖慢开发速度,并导致更糟糕的、更多bug的产品。


原文作者:Michael Foord

原文链接:

https://opensource.com/article ... sting
  查看全部
软件工程规则和测试积累的最佳实践,能帮助企业显著节省时间,减少痛点。良好的测试实践既可以确保质量标准,也可以指导和塑造每个程序员的发展。

小数今天推送的这篇文章,文中的许多原则都与测试实践和理想有关,有一些还是Python特有的。正如本文作者所说,程序员的那些固执己见,强烈的意见表达和坚持,往往是激情的最好表现。

1. YAGNI:不要编写现在尚不需要,而将来可能需要的代码。现在的代码不可避免地会变成死代码或需要重写,因为未来的用例总是与设想的不同。如果把代码放在未来的用例中,在代码审查中要提出质疑。(例如,可以并且必须设计API来允许将来的用例,不过,这是另外一个问题。)

注解代码也是如此。如果一个注释代码块进入发行版,它就不应该存在。如果是可以恢复的代码,创建一个ticket,并引用代码删除的提交散列。YAGNI 是敏捷编程的核心元素。Kent Beck提供的极限编程解释(Extreme Programming Explained)就是最好的参考。


2.测试本身不需要测试。用于测试的基础架构,框架和库需要测试。除非确实需要,通常不要测试浏览器或外部库。测试你写的代码,而并非其他人的。

3.第三次编写相同代码时,是将其抽取到通用帮助器(并为其编写测试)的正确时机。测试中的辅助功能不需要测试; 当把它们分解出来并进行重用时,才需要测试。到第三次编写类似的代码时,会清楚地知道正在解决什么样的问题。

4.涉及到API设计:简单的事情简单化; 复杂的事情可能如果可能也简单化。首先设计一个简单的情况,如果可能,最好使用零配置或参数化。为更复杂和更灵活的用例添加选项或其他API方法。


5.快速失败。尽可能早地检查输入,并在无意义的输入或无效状态上失败,使用异常或错误响应,来确定问题。允许代码“创新”,也就是说,通常情况下,不要对输入验证进行类型检查。


6. 单元测试是对行为单元的测试,而不是对实现单元。改变实现,而不是改变行为或被迫改变任何测试,当然这点并不是总能实现。在可能的情况下,将测试对象视为黑盒子,通过公共 API 进行测试,而无需调用私有方法或修改状态。


对于一些复杂的场景,比如一些特定复杂状态下,测试行为找到一个难以理解的错误。编写测试确实有助于解决这个问题,因为它会迫使你在编写代码之前,考虑清楚代码的行为以及如何测试。测试首先鼓励更小,更模块化的代码单元。

7.对于单元测试(包括测试基础结构测试),应该测试所有的代码路径。100%的覆盖率是一个很好的起点。你不能涵盖所有可能的排列/组合状态。在有很好的理由时,代码路径才能被测试。缺少时间不是一个好的理由,这往往导致最终花费更多时间。好的理由包括:真正无法测试,在实践中不可能实现,或者在测试中其他地方被覆盖。没有测试的代码要承担责任。衡量覆盖率,并拒绝降低覆盖率的百分比是朝正确方向前进的一种方法。


8.代码是敌人:可能出错,需要维护。少写代码。删除代码。不要编写你不需要的代码。

9.随着时间的推移,代码注释不可避免地成为谎言。实际上,很少有人在事情发生变化时更新评论。通过良好的命名实践和已知的编程风格,努力使代码有可读性和自我记录。

不明确的代码确实需要注释,比如围绕一个模糊的错误或不可能的条件,或者必要的优化。

10.防守地写。要总是想可能出现什么问题,无效输入会发生什么,什么可能导致失败,这有助于在错误发生前发现错误。

11.如果逻辑无状态且无副作用,则易于进行单元测试。将逻辑分解成独立的函数,而不是混合成有状态和副作用的代码。将有状态和带副作用的代码分离成更小的函数,可以更容易地模拟和单元测试。副作用确实需要测试,测试一次并在其他地方进行模拟,是比较好的做法。

12.Globals are bad。功能优于类型,对象比复杂的数据结构更好。

13.使用 Python 内置类型和方法比编写自己的类型更快(除非用C编写)。如果考虑性能,尝试解决如何使用标准内置类型而不是自定义对象。

14. 依赖注入是一种有用的编程模式,可以清楚了解依赖关系。(让对象,方法等接收依赖关系作为参数,而不是自己实例化新的对象。)这是一种交换,使API签名更加复杂。如果完成依赖项需要使用10个参数,说明代码太多了。


15. 越需要模拟测试代码,它就会越糟糕。需要实例化和放置的代码越多,用来测试特定的行为,代码就越糟糕。测试的目标是小型可测试单元,和更高级别的集成和功能测试,来测试这些单元是否正确地协作。


16.面向外部的 API 是要“预先设计”的,它关系到未来用例。改变 API 对自己和用户来说都是一种痛苦,而创造向后兼容性是非常可怕的,尽管有时不可避免。精心设计面向外部的API,仍然坚持“简单的事情简单化”的原则。


17.如果一个函数或方法超过30行代码,就要考虑分解。好的最大模块大小约为500线。测试文件往往比这个更长。


18.不要在难以测试的对象构造函数中工作。不要把代码放在__init__.py中。程序员不希望在__init__.py找到代码。


19. DRY(Don’t Repeat Yourself不要重复自己)在测试中比在生产中重要得多。单个测试文件的可读性比可维护性更重要(突破可重用的块)。这是因为测试是单独执行和读取的,而不是作为大系统的一部分。过多的重复意味着可重用的组件可以方便地创建,但是与生产相比,测试的重要性低得多。


20.当看到需要并有机会时进行重构。编程是关于抽象的,抽象映射越接近问题域,代码就越容易理解和维护。随着系统有机地增长,需要为扩展用例而改变结构。系统超出抽象和结构,而不改变它们成为技术债务,这会更痛苦,更缓慢,更多bug。包括重构成本,包括对功能的预估。你把债务拖得越久,它积累的利息就越高。Michael Feathers 撰写了一本关于重构和测试的书籍,其中着重介绍了遗留代码。

21.正确的编写代码第一,速度第二。处理性能问题时,请务必在修复之前进行配置。瓶颈通常出乎你的意料。编写难懂的代码如果是为了速度更快,为此你进行了配置并证明这么做是值得的,那么也仅仅是速度上值得而已。编写一个测试,训练正在配置的代码,让它知道什么情况下会变得更简单,并且留在测试套件中,来防止性能下降。(通常情况下,添加计时代码总是会改变代码的性能特点,使性能变得经常差强人意。)


22.更小范围的单元测试在失败时会提供更有价值的信息。要判定错误,有一半的系统测试行为的测试需要依据更多的调查。一般来说,运行时间超过0.1秒的测试不是单元测试。没有所谓的慢单元测试。通过严格范围的单元测试测试行为,你的测试可以作为代码实际规范。理想情况下,如果有人想了解你的代码,应该能够将测试套件作为行为的“文档”。


23. “这里没有发明”并不像人们所说的那么糟糕。如果我们编写代码,我们知道它的作用,知道如何维护它,可以自由地扩展和修改它。这是遵循了YAGNI的原则:我们有需要用例的特定代码,而并非通用代码,通用代码会给我们不需要的部分带来复杂性。另一方面,代码是敌人,拥有更多的代码没有好处,当引入新的依赖关系时需要考虑权衡。


24.共享代码所有权是目标。孤立的知识没什么好,这意味着至少要讨论、记录贯彻设计决策和实施决策。代码审查时开始讨论设计决策是最糟糕,因为在编写代码之后进行彻底的更改太难克服了。当然,在Review时指出和修改设计错误,比永远不总结不思考要好得多。


25.  Generators rock! 与有状态的对象相比,它们用于迭代或重复执行通常更短,更容易理解。


26.让我们成为工程师!设计、建立强大和良好实施的系统,而不是增加有机怪物。编程是一个平衡的行为,我们并不总是建造火箭飞船,过度设计(onion architecture洋葱架构)与设计不足的代码同样令人痛苦。罗伯特•马丁(Robert Martin)所做的几乎任何事情都值得一读,“ 干净架构:软件结构和设计指南”( Clean Architecture: A Craftsman’s Guide to Software Structure and Design )是这方面的好资源。设计模式( Design Patterns)是每个工程师应该阅读的经典编程书籍。


27.间歇性地失败的测试会侵蚀测试套件的价值,以至于最终每个人都忽略测试运行的结果。修复或删除间歇性失败的测试是痛苦的,但值得努力。


28.一般来说,尤其是在测试中,等待一个具体的改变,而不是任意时间内sleeping。Voodoo sleeps 很难理解,而且会放慢测试套件。


29.至少要看到你的测试失败过一次。将一个蓄意的 bug 放入让它失败,或在测试行为完成之前运行测试。否则,你不知道你真的在测试。偶尔写写测试代码实际并不测试任何东西,或写永远不会失败的测试,都是很容易的。


30.最后,管理要点:持续的功能研发是开发软件的一个可怕方法。不让开发人员在工作感到骄傲, 就不会从中获得最大的利益。不解决技术债务,会拖慢开发速度,并导致更糟糕的、更多bug的产品。


原文作者:Michael Foord

原文链接:

https://opensource.com/article ... sting
 

万字雄文讲透现代网络负载均衡和代理技术,终于弄懂负载均衡那点事

杨y 发表了文章 • 0 个评论 • 144 次浏览 • 2018-01-18 00:35 • 来自相关话题

最近我注意到,针对负载均衡和代理这两项现代网络技术,有教育意义的介绍性材料相当稀缺。这引起我的思考:为什么会这样?在可靠的分布系统的架构中,负载均衡是核心概念之一,这一地位要求有对应的高质量信息。
然而经过搜索之后,发现这方面的内容的确匮乏。Wikipedia 上的 负载均衡 和 代理服务器 页面只包含了一些相关主题的概念,这些概念的阐述,尤其是微服务架构相关的部分显得相当概括和晦涩。Google 搜索 Load Balancing,则会出现一些供应商页面,充斥了各种时髦用词,却罕有细节。

本文里我会尝试对现代网络负载均衡和代理技术进行一些讲解,来弥补上述的材料缺失。平心而论,相关内容中的大量主题足以支撑起一本专著。为了符合我对博客长度的控制习惯,我会将其中一些复杂主题进行概括和提炼,用简单的概要方式进行陈述;根据读者的兴趣和反馈,我可能会在后续文章中对某些话题的细节进行更多的阐述。

上面的内容就是我开始写作本文的动机,下面开始正式内容。

1
网络负载均衡和代理是什么?

Wikipedia 对负载均衡的定义 是:

In computing, load balancing improves the distribution of workloads across multiple computing resources, such as computers, a computer cluster, network links, central processing units, or disk drives. Load balancing aims to optimize resource use, maximize throughput, minimize response time, and avoid overload of any single resource. Using multiple components with load balancing instead of a single component may increase reliability and availability through redundancy. Load balancing usually involves dedicated software or hardware, such as a multilayer switch or a Domain Name System server process.

中文版:

负载平衡(Load balancing)是一种计算机网络技术,用来在多个计算机(计算机集群)、网络连接、CPU、磁盘驱动器或其他资源中分配负载,以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。使用带有负载平衡的多个服务器组件,取代单一的组件,可以通过冗余提高可靠性。负载平衡服务通常是由专用软件和硬件来完成。

上面的定义不仅包含了网络,还包含了计算的所有方面。操作系统、网络以及容器编排器等都有各自的负载均衡技术,用于使用各自的资源进行各自的任务调度。本文仅就网络负载均衡进行探讨。

图 1:网络负载均衡概览

图 1 对网络负载均衡进行了一个高层次的概括。多个客户端向多个后端发起资源请求,负载均衡器处于客户端和后端之间,简单来说完成如下任务:

服务发现:系统中有哪些后端可用?这些后端的地址(也就是:负载均衡器如何同这些后端通信)?

健康检查:哪些后端是健康的可以用于接收请求?

负载均衡:用什么算法来把独立的请求分发给健康的后端?

在分布式系统中合理的使用负载均衡能带来很多好处:

命名抽象:每个客户端不再需要知道每一个后端(服务发现),客户端可以通过预定义的机制来找到负载均衡器,然后让负载均衡器完成命名解析功能。这些机制包括内置库,以及路人皆知的 DNS/IP/端口 地址,后面会深入讨论。

错误隔离:通过健康检查以及一些其他的算法和技术,负载均衡器的路由方法能够有效的绕过瘫痪或过载的后端。这样运维人员在面对系统故障时,就可以更加从容的进行错误处理。

成本和性能收益:分布式系统的网络的一致性比较差。系统通常要跨越多个网络区域。同一区域内,网络资源通常是低售的;而在跨区域的情况下,超售则是常态(超售和低售的鉴别,是通过网卡上可消耗的带宽和路由器之间的可用带宽进行比对得出的结论)。智能的负载均衡会尽可能保证通信在同一区域内进行,从而提高性能(降低延迟)并降低总体系统成本(降低区域间的带宽和光纤需求)。

负载均衡器 vs 代理服务器

业内谈到网络负载均衡器,Load Balancer 以及 Proxy 这两个术语经常会同样对待,本文中也把这两个词条等价处理(卖弄一下:并非所有的代理都是负载均衡器,但是负载均衡是主流代理的首要功能)。

有人可能会问,有的负载均衡功能是作为客户端库的内置功能完成的,这种负载均衡器就不是代理服务器。这一话题本就容易混淆,这一质问更加让人糊涂。文中会详述这种负载均衡器的拓扑,这种嵌入的负载均衡方式只是代理的一种特例,应用通过内嵌的库来完成代理职能,跟典型的负载均衡器的区别仅在于进程内外而已,其整体抽象是一致的。

四层(连接/会话)负载均衡

业界在讨论负载均衡技术的时候,经常会分为两类:L4 和 L7。这一分类来源于 OSI 模型的四层和七层的定义。OSI 模型无法很好的描述负载均衡方案中的复杂性,一个四层负载均衡在完成传统的四层协议任务例如 UDP 和 TCP 之外,往往还会加入了其他层次的内容。例如一个四层的 TCP 负载均衡还支持 TLS 功能,这算七层负载均衡了么?

图 2:TCP 终端四层负载均衡

图 2 展示了一个传统的四层 TCP 负载均衡器。这个例子中,客户端向负载均衡器发起了一个 TCP 连接,负载均衡器 终结 了这一连接(也就是说直接响应了 SYN),接下来选择一个后端,然后创建了到后端的新的 TCP 连接(就是发起了新的 SYN)。图中的细节不需太过关注,后面的四层负载均衡章节会进行详细讨论。

本节的关键点是四层负载均衡一般只在四层的 TCP/UDP 进行操作。笼统的说,负载均衡器负责操作这些字节,保证同一会话的字节们只跟同一个后端打交道。四层负载均衡对通信中的应用细节是一无所知的。通信内容可以是 HTTP、Redis、MongoDB 或者任何应用协议。

七层(应用)负载均衡

四层负载均衡很简单,目前还在大面积使用。四层负载均衡有什么短处,以至于需要七层(应用)负载均衡呢?例如下面几个四层的案例:

两个 gRPC/HTTP2 客户端要连接到后端,所以通过四层负载均衡器来完成这一过程。

四层负载均衡器为每个接入的 TCP 连接创建一个外发的 TCP 连接,这样就有了两个接入、两个外发的连接。

然而客户端 A 的请求频率是每分钟 1 请求,而客户端 B 的频率是每秒钟 50 请求。

在上述场景中,为客户端 A 服务的后端,其负载水平仅相当于为客户端 B 服务的后端的约 1/3000 左右,这明显违背了负载均衡器的初衷。在所有多工、保持连接的协议中都会发生这样的情况(多工意思是在单一四层连接中并行发送应用请求;保持连接则意味着在没有活动请求的情况下,也不会关闭连接)。出于性能方面的考虑(创建连接的成本通常较高,尤其是当使用 TLS 对连接进行加密的情况下),所有的现代协议都包含这两个特性,所以随着时间的推移,四层负载均衡的负载不均的情况会越发明显。七层负载均衡能够解决这一问题。

图三:HTTP/2 七层终端负载均衡

图 3 描述了七层的 HTTP/2 负载均衡。这里客户端发起了对负载均衡的单个连接。负载均衡器连接到了两个后端。当客户端向负载均衡器发送两个 HTTP/2 流的时候,两个流会分别送往不同后端。这样多工客户端的大量不同的请求会被高效的分发给多个后端。这就是七层负载均衡对现代协议的重要性的来由(因为对应用流量的洞察能力,七层负载均衡还有很多其他好处,后面会详细描述)。

七层负载均衡和 OSI 模型

之前四层负载均衡章节中说过,用 OSI 模型来描述负载均衡是有困难的。OSI 描述的第七层,涵盖了负载均衡的多方面功能的臭显。比如对 HTTP 来说,有以下几个低级一些的层次:

可选的 TLS。网络界对 TLS 究竟应该属于 OSI 模型的哪一层素有争议。为讨论方便,我们放在七层。

物理的 HTTP 协议(HTTP/1或 HTTP/2)。

逻辑 HTTP 协议(Header、Body 和 Trailer)。

消息协议(gRPC、REST 等)。




一个成熟的的七层负载均衡器应该照顾到上面描述的每一层次。另一个七层负载均衡器可能只支持七层分类中的特性的一个子集。总而言之,七层负载均衡器的范畴包含了远超四层的为数众多的功能(例子中只提到了了 HTTP;Redis、Kafka、MongoDB 等也都是七层应用协议的例子,也都应受益于七层负载均衡)。

2
负载均衡器特性

下面简单汇总一下负载均衡器的高层功能。并非所有负载均衡器都提供了所有功能。

服务发现

服务发现就是负载均衡器用于决定可用后台列表的过程。这一功能的实现方式花样百出,下面举一些例子:

静态配置文件。

DNS。

Zookeeper、Etcd、Consul 等。

Envoy 的 统一数据平面 API。

健康检查

负载均衡器使用健康检查功能,来检测后端是否可用。健康检查有两种实现思路:

主动式:负载均衡器周期性的向后端发送 ping (例如一个发送到/healthcheck端点的 HTTP 请求),以此判断后端的健康情况。

被动式:负载均衡器通过对主数据流的分析来确定健康情况。比如一个四层负载均衡器,在发现连续三个连接错误的情况下,就会判定一个后端不可用;七层负载均衡可能会在连续三个 HTTP 503 响应之后判定这一后端为不健康状态。

负载均衡

是的,负载均衡器必须为负载做均衡。有了一系列的健康后端,如何选择后端来响应一个请求或者连接呢?负载均衡算法是一个活跃的研究领域,有 Round Robin 这样的简单办法,也有通过延迟和后端负载情况进行判断的复杂方案。 Power of 2 least request load balancing 一文,介绍了最流行的兼顾性能和简易的负载均衡算法之一。

随机选择两个后端,进一步选择其中负载较低的一个。

Session 粘连

在某些应用中有一个重要需求:同一会话的请求需要到达同一后端。对于缓存、临时复杂状态等场景来说这是很必要的。对于“同一会话”的定义有多种形式,可能包括 HTTP Cookie、客户端连接的属性以及其他属性。很多七层负载均衡器具有一些对会话粘连的支持。然而我认为会话粘连是一种天然易碎的情况(处理会话的后端可能会瘫痪),所以对于依赖会话的系统设计应该多加小心。

TLS 终端

TLS 这一话题,不管是边缘服务还是服务间通讯,都值得大书特书。因此很多七层负载均衡器在 TLS 处理方面都做了大量工作,其中包含终端、证书校验和绑定,使用 SNI 提供证书等功能。

观测性

我常说:“观测性、观测性、观测性。”,网络是一个天生不可靠的东西,负载均衡器应该提供状态、跟踪以及日志,协助运维人员甄别故障,从而进行修复。负载均衡器的检测输出差距很大。高级的负载均衡器供应包含数字统计、分布式跟中和自定义日志的大量输出。我认为增强的观测性并不是从天而降的,负载均衡器需要做出很多附加工作来完成这一任务。对性能造成的负面影响,相对于这一系列数据的好处来说,不值一提。

安全性和拒绝服务攻击防范

在边缘部署拓扑(后面会讲解)中,负载均衡器经常需要实现各种包含频率限制、认证以及 DoS 防范(例如 IP 地址的标记和辨识、Tarpitting等方式)等在内的安全功能。

配置和控制平面

负载均衡器应该是可配置的。在大规模部署中,这是一个重要的工作量。通常来说,用来配置负载均衡器的系统被称为“控制平面”,会有多种实现。拙作 Service Mesh Data Plan vs Control Plan 中对这一部分内容作了更深入的探讨。

还有很多

这部分只是对于负载均衡器的功能层面作了一些介绍。下面还会在七层负载均衡器方面做更多的深入讨论。

3
负载均衡器的拓扑分类

我们已经对负载均衡器的概念作了一些概括的介绍,四层和七层负载均衡器的区别,以及负载均衡器特性的汇总,接下来我们会针对分布式系统中的负载均衡器部署拓扑进行一些探讨(下面的每一种拓扑都是适用于四层和七层负载均衡器的)。

中间代理

图 4:中间代理负载均衡拓扑

图 4 描述的这种拓扑对多数读者来说都是最熟悉的。这一类别包括了 Cisco、Juniper、F5 等硬件产品;云软件解决方案例如 Amazone 的 ALB 和 NLB 以及 Google 的 Cloud Load Balancer,还有 HAProxy、NGINX 以及 Envoy 这样的纯软件自主方案。中间代理方案的优势在于对用户提供的简便性。

一般情况下用户只要通过 DNS 连接到负载均衡器即可,无需担心其他情况;弱势在于,负载均衡器存在单点失败的风险,同时也是可能的性能瓶颈。中间代理通常是一个不便运维的黑盒子。问题出现在哪里?是客户端还是物理网络?是中间代理还是后端?很难界定。

边缘代理

图 5:边缘代理负载均衡拓扑

图 5 实际上是中间代理的一种变体,这种负载均衡器可以通过 Internet 进行访问。在这一场景下,负载均衡器通常需要提供一些附加的 “API 网关”类功能,例如 TLS 终端、频率限制、认证以及流量路由等。优势和劣势跟中间服代理类似。在一个大的面向 Internet 的分布式系统中,边缘服务器通常是一个必要的组成部分。

客户端通常会使用某个不受服务提供商控制的网络库,通过 DNS 来访问这一系统(后面将会讨论的嵌入客户库或者 Sidecar 代理拓扑都不适合直接运行在客户端)。另外为了安全方面的考虑,为所有的面向 Internet 的流量使用单一的网关来提供入站流量是一个普遍要求。

嵌入式客户库

图 6:通过嵌入客户端库实现负载均衡

为了克服随中间代理而出现的单点失败以及性能问题,很多成熟架构把负载均衡直接植入如图 6 所示的客户端库中。不同的库所支持的功能差别很大,此类产品中最知名的功能丰富的包括 Finagle、Eureka/Ribbon/Hystrix 以及 gRPC(大致基于 Google 的一个称为 Stubby 的内部系统)。这种方式的好处是把所有负载均衡特性完全分布到每个客户端,从而避免了前面说到的单点失败和性能瓶颈。

这种做法的弱势也很明显,一个组织使用的所有语言,都需要实现这种客户端库。分布式架构下,这种多语言支持的要求会越来越多。这种环境里,每种语言的网络库实现造成的成本会让人望而却步。最后,在大的服务架构中进行库升级也是一个很大的挑战,而在生产环境中并行运行不同的版本,又会给运维造成更大压力。


结合上面的优劣势分析,可以知道,在能够限制编程语言使用,并克服升级痛苦的情况下,这种架构是可以获得成功的。

Sidecar 代理

图 7:Sidecar 代理实现负载均衡

嵌入式客户库的一个变体就是图 7 中的 Sidecar 代理拓扑。近年来,这一拓扑以 “Service Mesh” 的概念日益流行。Sidecar 代理背后的思路是,以进程间通信造成的些许延迟为代价,在无需顾虑编程语言锁定的情况下获得嵌入客户端库的各种优点。目前流行的 Sidecar 负载均衡包括 Envoy、NGINX、HAProxy 以及 Linkerd,我的两篇文章:Introducing Envoy 和 Service Mesh Data Plan vs Control Plan 对这种结构进行了更细致的描写。

不同负载均衡器拓扑的总结和优劣势

中间代理拓扑是最简单的最典型的方式。他的弱点在于:故障单点、伸缩瓶颈以及黑箱操作。

边缘代理拓扑和中间代理类似,通常无法忽略。

嵌入客户端库的方式提供了最好的性能和伸缩性,不过面向多种语言的开发,和升级所有服务的库都是很大的挑战。

Sidecar 代理拓扑比嵌入式客户端库要弱,但也避免了这种方式的两大难点。

总的来说,我认为在服务对服务的情况下,Sidecar 代理拓扑(Service Mesh)会逐渐代替所有其他拓扑形式。为了处理进入 Service Mesh 之前的流量,边缘代理拓扑会长期存在。

4
四层负载均衡的现状

四层负载均衡器还有用么?

本文已经谈论了很多七层负载均衡器对现代协议的好处,后面还会谈到七层负载均衡的功能细节。这是否意味着四层负载均衡器无需存在了?不是的。虽然我认为最终七层负载均衡会完全在服务对服务的场景中取代四层负载均衡器,但四层负载均衡器对边缘通信还是非常有意义的,这是因为所有现代的大型分布式架构都是用了两层的四层/七层负载均衡架构来处理互联网流量。在七层负载均衡器之前部署独立的四层负载均衡器的好处是:

七层负载均衡器要在应用层面进行更多的精密分析、变换以及路由工作,对于原始流量(每秒数据包或每秒字节数)的负载,其能力要弱于优化过的四层负载均衡器。这一现实使得四层负载均衡器更便于应对拒绝服务攻击(例如 SYN flood、通用包 flood 攻击等)。

相对于四层负载均衡器,七层负载均衡器的开发更加活跃,部署更加频繁,也会有更多 Bug。有了前置的四层负载均衡器,就可以在七层负载均衡器升级期间进行健康检查和排空,现代四层负载均衡器通常使用 BGP 和 ECMP(后续章节会详细讲解),七层负载均衡的部署通常会较为简单。最后因为七层负载均衡器相对来说复杂度较高,因此也更容易出现问题,有了前端的四层负载均衡,就可以在出现问题的时候利用路由功能绕过故障节点,提高系统的总体稳定性。

下文中我会讲到集中不同设计的中间/边缘四层负载均衡器。后面提到的设计通常是无法用在客户库或 Sidecar 拓扑中的。

TCP/UDP 终端负载均衡器

图 8:四层终端负载均衡器
还在应用的第一种四层负载均衡器是图 8中的终端负载均衡器。这和我们介绍四层负载均衡的时候讲到的内容是一致的。这种类型的负载均衡器中,使用了两个的独立的 TCP 连接:一个用于客户端和负载均衡器之间;另一个用在负载均衡器和后端之间。

四层终端负载均衡器还有两个原因:

实现相对简单。

靠近客户端的连接终端对性能有显著影响。尤其是如果客户使用有损网络(例如蜂窝网)的话,在进入稳定的有线传输到最终目的之前,是容易发生重传的。换句话说,这种负载均衡器适用于在存在点(Point of Presence )场景下的原始 TCP 连接。

TCP/UDP 透传负载均衡器

图 9:透传负载均衡器

四层负载均衡器的另一种类型就是图 9所说的透传负载均衡器。这种类型的负载均衡过程中,TCP连接没有被负载均衡器终结,每个链接的数据包,在经过连接分析和网络地址转换(NAT)过程之后,都被转发给一个选中的后端。首先让我们定义一下连接跟踪和 NAT:

连接跟踪:跟踪全部活动 TCP 连接的过程。这里包括很多内容,例如握手是否完成,是否收到 FIN,连接发呆了多久,这个连接转发给哪一个后端等。

NAT:是使用连接跟踪数据,来更改数据包的 IP/端口信息使之穿过负载均衡器的过程。

有了连接跟踪和 NAT,负载均衡器就能把客户端的 TCP 流量几乎原封不动的的转发给后端。例如客户端同1.2.3.4:80进行通信,选中的后端是10.0.0.2:9000。客户端的 TCP 数据包会到达位于1.2.3.4:80的负载均衡器。负载均衡器会把目标 IP 和端口替换为10.0.0.2:9000;同时还会把源 IP 替换为负载均衡器的 IP。当后端响应 TCP 连接时,数据包就会返回给负载均衡器,负载均衡器中的链接跟踪和 NAT 再次发挥作用,反向送回数据包。

为什么会使用这一种负载均衡器,而不是前面提到的终端型呢?

性能和资源消耗:透传型的负载均衡器没有终结 TCP 连接,无需缓存任何的 TCP 连接窗口。每个连接的状态存储非常小,通常使用高效的哈希表查询即可。正因如此,相对终端负载均衡器来说,透传型负载均衡器能够处理更大数量的活动链接,单位时间内处理更多的数据包。

允许后端进行拥塞控制:TCP 拥塞控制 是一种机制,让 Internete 端点对外发数据进行流量控制,防止超量使用带宽和缓冲。

为直接服务器返回(Direct Server Return = DSR)做基线,以及四层负载均衡集群:透传负载均衡也是高级四层负载均衡(例如后面将要说到的 DSR 和使用分布式一致性哈希的集群)的基础。

Direct Server Return (DSR)

图 10:四层 DSR

图 10展示的就是 DSR 负载均衡。DSR 构建在前文提到的透传负载均衡器的基础之上。DSR 是一种优化方案,只有入站/请求数据包通过负载均衡;出站/响应数据包绕过负载均衡器直接返回给客户端。使用 DSR 方案的有趣之处在于,很多负载的响应比请求数据量大很多(比如典型的 HTTP 请求和响应)。假设 10% 的流量是请求,另外 90% 是响应,如果使用了 DSR 负载均衡,仅需要 1/10 的容量就能够满足系统需要。从前的负载均衡非常昂贵,这一方案能够显著降低系统成本并提高可靠性(更少就是更好)。DSR 负载均衡器用下面的方式扩展了透传负载均衡的概念:

由于响应包不再经过负载均衡器,所以连接跟踪仅有部分数据,负载均衡器无法知道完整的 TCP 连接状态。然而还是可以通过对客户数据包的观察,对发呆超时的情况来推断具体状态。

负载均衡器通常使用 GRE 来封装 IP 包,并从负载均衡器发送到后端。这样当后端接收到封装后的数据包,可以解包并获得客户端的端口和地址。这样后端就能直接跨过负载均衡器直接发送响应包给客户端了。

DSR 负载均衡器的一个重要部分就是:后端部分的参与了负载均衡过程。后端需要合理的配置 GRE 隧道,并且需要根据网络的低级细节来配置自己的连接跟踪以及 NAT 等。

注意不管是 DSR 还是透传负载均衡器,其中的连接跟踪、NAT、GRE 等组成部分都有很多不同设计方式。这些设置从负载均衡器到后端都会涉及。这部分内容超出了本文的范围,就不再深入进行了。

使用高可用配对方式实现容错

图 11:使用 HA 对和连接跟踪实现容错

到现在,我们要考虑四层负载均衡的容错设计了。不管是 DSR 还是透传负载均衡都需要一定数量的链接跟踪和状态数据存储在负载均衡器中。负载均衡器宕机了会怎样?——所有经过这一负载均衡器的连接都会断掉。可能对应用产生显著影响。

历史上,四层负载均衡器是一种从典型供应商(Cisco、Juniper、F5 等)采购的硬件。这些设备非常昂贵,能够处理大量通信。为了防止单点失败导致的所有连接中断,引发应用故障,负载均衡器通常会使用高可用配对的方式进行部署,如图 11 所示。典型的高可用负载均衡器配置会满足如下设计:

一对高可用边缘路由器提供一系列的虚拟 IP(VIP)。这些边缘路由器使用边界网关协议(BGP)来发布虚拟 IP。主要边缘路由器的 BGP 优先级高于备用边缘路由器,所以正常情况下他会处理所有流量(BGP 是一个超级复杂的协议;为了行文方便,可以理解 BGP 是一种机制,这种机制让网络设备可以宣称自身能够处理来自其他网络设备的流量,并且每个连接都会有一个权重,从而影响连接的通信)。

类似的,主要四层负载均衡向 BGP 权重较高的边缘路由器宣告可用,所以在通常情况下,他会处理所有流量。

两个边缘路由器和两个负载均衡器是交叉连接的,这意味着如果一个边缘路由器或者一个负载均衡器宕机,或者因为某些原因 BGP 宣布失效,备用设备就会接入,承载所有流量。

上面的设置是目前很多互联网上的高流量应用还在持续使用的方式,但是这种方案有一些副作用:

VIP 必须通过高可用负载均衡器对流量进行正确的分配。如果单一 VIP 的容量超过了 HA 对,则 VIP 需要分割为多个 VIP。

系统资源使用率很低。通常会有一半的容量在闲置。过去的负载均衡器非常昂贵,所以这一闲置成本也是很高的。

现代分布式系统设计要求比主备模式更好的容错设计。例如一个系统需要在多个同时出现故障的情况下保持运行。高可用负载均衡对如果遭遇同时故障,就会导致完全瘫痪。

供应商提供的硬件设备价格昂贵,会导致对特定厂商的依赖。使用支持水平扩展的软件方案对商业硬件设施进行替换,是目前普遍存在的迫切需要。

使用分布式一致性哈希进行容错和伸缩

图 12:四层负载均衡器和一致哈希实现容错和伸缩

前文介绍了通过高可用配对的方式来进行负载均衡器的容错设置,以及随之而来的问题。千禧年初,一些大的互联网基础设施提供商开始设计和部署新的图 12 模式的并行四层负载均衡系统。这类系统的目标是:

解决使用成对 HA 模式设计的负载均衡方案带来的所有问题。

从厂商专属的专利硬件模式的负载均衡器中迁移出来,使用标准服务器和网卡配合商业软件方案进行替代。

四层负载均衡器的设计是 fault tolerance and scaling via clustering and distributed consistent hashing 的最佳引用,具体工作模式是:

N 个边缘路由器在同一 BGP 权重上,声明所有的 任播 VIP。使用 ECMP(等价多路径路由) 来保证所有单一 Flow 能够到达同一个边缘路由器。一个 Flow 通常是一个由源 IP/端口和目的 IP/端口 构成的元组。(简单说,ECMP 是一个在使用一致性哈希连接的独立加权网络上分发数据包的方式)。边缘路由器并不在意哪些数据包去了哪里。一般会倾向于把来自于一个 Flow 所有数据包发送给同一套连接,以此避免乱序包导致的性能损失。

N 个四层负载均衡器向边缘路由器在同一个 BGP 权重上声明所有的 VIP。再次借助 ECMP,边缘路由器会选择为同一个 Flow 选择同一个负载均衡器。

每个四层负载均衡器会进行部分的连接跟踪,为这一 Flow 使用一致性哈希选择一个后端。从负载均衡器到后端的数据包会使用 GRE 进行封装。

接下来使用 DSR 将相应包直接从后端通过边缘路由器发送会客户端。

四层负载均衡器使用的一致性哈希算法是一个活跃的研究领域,其中涉及合理分配、减小延迟、后端变更成本以及最小化内存开支等各方面要素。这方面的完整讨论也超出了本文范围。

接下来看看这种设计如何克服 HA 配对方式的缺点:

新的边缘路由器和负载均衡器可以按需加入。一致性哈希会在各个层次上使用,在加入新机器的时候,尽可能降低受影响的 Flow 数量。

在保持对突发消耗的支持能力以及容错能力的同时,可以提高资源的使用率。

边缘路由器和负载均衡都可以使用使用普通硬件,仅是传统硬件负载均衡成本的几分之一(下文会进一步说明)。

行文至此,有读者可能会问:“为什么不让边缘路由器直接通过 ECMP 和后端进行通信?为什么我们还需要负载均衡器?”。答案是 DoS 防范以及后端运维难度。如果没有负载均衡器支持,每个后端都需要加入 BGP,而且难于进行滚动更新。

所有的现代四层负载均衡系统都在向着这一方案(或其变体)迁移。两个最为公众所知的例子就是 Google 的 Maglev 以及 Amazon 的 Network Load Balancer (NLB)。目前还没有任何开源负载均衡器实现了这一设计,然而据我所知,有公司要在 2018 年发布一个这样的产品。我很期待他的出现,这一产品将会填补开源网络组件的重要空白。

当前七层负载均衡的技术状态

Current state of the art in L7 load balancing The proxy wars in tech currently is quite literally the proxy wars. Or the "war of the proxies". Nginx plus, HAProxy, linkerd, Envoy all quite literally killing it. And proxy-as-a-service/routing-as-a-service SaaS vendors raising the bar as well. Very interesting times!

是的,的确是这样。近几年我们看到七层负载均衡/代理技术的开发工作开始复兴。随着分布式微服务系统的不断推进,这方面也会不断进步。从基础上看,目前对于靠不住的网络的依赖越发严重,带来更高的运维难度。从长远看,自动伸缩、容器编排等技术的大量使用,意味着静态 IP、静态文件的时代已经过去了。系统不仅更多的使用网络,而且更加动态,需要新的负载均衡功能。在本节中我们简单归纳一下现在七层负载均衡器的功能。

协议支持

现代七层负载均衡器加入了很多不同协议的显式支持。负载均衡器对应用通讯认识越多,就越能做好监控输出、高级负载均衡和路由等功能。例如目前 Envoy 显式的支持七层协议解析和路由的范围包括 HTTP/1、HTTP/2、gRPC、Redis、MongoDB 以及 DynamoDB。包括 MySQL 和 Kafka 在内的更多协议会逐渐添加进来。

动态配置

如上文所述,分布式系统的大行其道,需要有动态配置能力来提高系统的动态和控制能力。Istio就是一个这种系统的例子。请参考 Service Mesh Data Plan vs Control Plan 来获取更多这方面的内容。

高级负载均衡

七层负载均衡器一般都有内置的高级负载均衡支持,例如超时、重试、频率控制、断路器、Shadow、缓冲、基于内容的路由等。

可观测性

上文中也提到过,负载均衡的一个常见功能,越来越多的动态系统被部署,调试难度也水涨船高。健壮的协议规范观测输出可能是未来七层负载均衡器要提供的最重要功能之一。统计数字、分布式跟踪以及可以定义日志的输出,目前已经成为对器层负载均衡解决方案的必须要求。

扩展性

现代七层负载均衡器需要能够简单的加入定制功能。这一功能可以通过编写可插接过滤器,并载入到负载均衡器的方式来实现。很多负载均衡器还支持脚本扩展,例如 Lua。

容错

在讲四层负载均衡的容错时颇费了一番口舌。七层负载均衡的容错又怎样呢?一般来说我们认为七层负载均衡器(的工作负载)是无状态的可抛弃的。使用普通软件就能够简单的对七层负载均衡器进行水平扩展。另外七层负载均衡的流量处理和状态跟踪的复杂度要远超四层。设置七层负载均衡器的 HA 配对在技术上是可行的,但会非常繁杂。

总的说来,不管是四层还是七层的负载均衡,业界都在尝试走出 HA 配对模式,转向一致性哈希为基础的水平扩展方式。

更多

七层负载均衡器正在高速发展。可以参考 Envoy 架构概览。

5
全局负载均衡和中心控制平面

图 13:全局负载均衡

未来会有越来越多的独立负载均衡器以商品设备的面目呈现。我认为真正的创新和商业机会来自于控制平面。图 13展示了一个全局负载均衡系统。在本例中有一些不同的东西:

每个 Sidecar 代理和三个不同区域的后端进行通信。

如图,90% 的流量会被发送到 C 区,A B 两区分别得到 5%。

Sidecar 代理和后端都会周期性的向全局负载均衡器进行汇报。这样全局负载均衡器就可以根据延迟、成本、负载、失败率等数据进行精密决策。

全局负载均衡周期性的使用当前的路由信息配置每个 Sidecar 代理。

全局负载均衡能做一些单一负载均衡器做不到的事情,例如:

对分区故障的自动检测和路由绕行。

应用全局的安全和路由策略。

使用机器学习和神经网络,对异常流量进行检测和防范,包括分布式拒绝服务攻击。

提供中央界面和可视化支持,让工程师能够以聚合的角度,对整个分布式系统进行监控和运维。

全局负载均衡器要成为现实,他的数据平面必须具有强大的动态配置能力。请参考我的博客:Envoy's universal data plane API,以及 Service Mesh Data Plan vs Control Plan 。

6
从硬件到软件的变革

这里只是简要的提到了硬件和软件的问题,主要聚焦在四层负载均衡高可用方面的历史问题。这一领域的业界趋势又如何呢?

这一推虽说略显浮夸,但却很好的描述了技术趋势:

历史上的负载均衡器和路由器都曾经是昂贵的专属硬件

逐渐的,多数三层四层网络设备都被替换为通用服务器硬件和网卡,以及基于 IPVS、DPDK 和 fd.io之类的框架的特定软件方案。一个现代的成本低于 $5k 的数据中心,运行 Linux 和自定义的基于 DPDK 的 user-space 应用,能够轻松用超小数据包跑满 80Gbps 的网络。另外廉价的基于 ASICs 的基础路由器/交换机也能够完成 ECMP 路由工作,并能支撑和通用路由器同级别的带宽和包速率。

Nginx、HAProxy 以及 Envoy 这样的七层软负载均衡,也正快速发展,逐步进入过去由 F5 这样的厂商的专属领域。此外,七层负载均衡器正激进的向通用软件方案的方向迈进。

同时,主要云提供商推动的 IaaS、CaaS 以及 FaaS 潮流,使得只有一小部分人需要理解物理网络(这属于黑科技,以及“我们不再需要深入了解”的范围了)。

7
结论,以及负载均衡器的未来

综上所述,本文的主旨:

负载均衡器是现代分布式系统的关键组件。

有两种负载均衡器:四层和七层。

四层和七层负载均衡器都与现代架构相关。

四层负载均衡器正在朝着基于一致性哈希的水平扩展方案的方向进行迁移。

由于动态微服务架构的成长,七层负载均衡器得以快速发展。

控制平面和数据平面的拆分,和全局负载均衡,是负载均衡的未来发展方向和机会来源。

业界正激进的迈向标准硬件和软件的开源解决方案。我相信传统的像 F5 这样的负载均衡厂商会被开源软件和云供应商取代。传统的路由器、交换机厂商,例如 Arista/Cumulus 等,短期内会有更好的发展,但最终也会被共有云提供商及其自研物理网络所取代。

总的说来,我认为这是计算器网络的奇迹年代。多数系统开始向开源和软件方向转变,极大的提高了迭代速度。未来,分布式系统又向无服务器计算进军,底层网络和负载均衡系统的复杂性也势必齐头并进,水涨船高。

原文:https://blog.envoyproxy.io/int ... 80236 查看全部
最近我注意到,针对负载均衡和代理这两项现代网络技术,有教育意义的介绍性材料相当稀缺。这引起我的思考:为什么会这样?在可靠的分布系统的架构中,负载均衡是核心概念之一,这一地位要求有对应的高质量信息。
然而经过搜索之后,发现这方面的内容的确匮乏。Wikipedia 上的 负载均衡 和 代理服务器 页面只包含了一些相关主题的概念,这些概念的阐述,尤其是微服务架构相关的部分显得相当概括和晦涩。Google 搜索 Load Balancing,则会出现一些供应商页面,充斥了各种时髦用词,却罕有细节。

本文里我会尝试对现代网络负载均衡和代理技术进行一些讲解,来弥补上述的材料缺失。平心而论,相关内容中的大量主题足以支撑起一本专著。为了符合我对博客长度的控制习惯,我会将其中一些复杂主题进行概括和提炼,用简单的概要方式进行陈述;根据读者的兴趣和反馈,我可能会在后续文章中对某些话题的细节进行更多的阐述。

上面的内容就是我开始写作本文的动机,下面开始正式内容。

1
网络负载均衡和代理是什么?

Wikipedia 对负载均衡的定义 是:

In computing, load balancing improves the distribution of workloads across multiple computing resources, such as computers, a computer cluster, network links, central processing units, or disk drives. Load balancing aims to optimize resource use, maximize throughput, minimize response time, and avoid overload of any single resource. Using multiple components with load balancing instead of a single component may increase reliability and availability through redundancy. Load balancing usually involves dedicated software or hardware, such as a multilayer switch or a Domain Name System server process.

中文版:

负载平衡(Load balancing)是一种计算机网络技术,用来在多个计算机(计算机集群)、网络连接、CPU、磁盘驱动器或其他资源中分配负载,以达到最优化资源使用、最大化吞吐率、最小化响应时间、同时避免过载的目的。使用带有负载平衡的多个服务器组件,取代单一的组件,可以通过冗余提高可靠性。负载平衡服务通常是由专用软件和硬件来完成。

上面的定义不仅包含了网络,还包含了计算的所有方面。操作系统、网络以及容器编排器等都有各自的负载均衡技术,用于使用各自的资源进行各自的任务调度。本文仅就网络负载均衡进行探讨。

图 1:网络负载均衡概览

图 1 对网络负载均衡进行了一个高层次的概括。多个客户端向多个后端发起资源请求,负载均衡器处于客户端和后端之间,简单来说完成如下任务:

服务发现:系统中有哪些后端可用?这些后端的地址(也就是:负载均衡器如何同这些后端通信)?

健康检查:哪些后端是健康的可以用于接收请求?

负载均衡:用什么算法来把独立的请求分发给健康的后端?

在分布式系统中合理的使用负载均衡能带来很多好处:

命名抽象:每个客户端不再需要知道每一个后端(服务发现),客户端可以通过预定义的机制来找到负载均衡器,然后让负载均衡器完成命名解析功能。这些机制包括内置库,以及路人皆知的 DNS/IP/端口 地址,后面会深入讨论。

错误隔离:通过健康检查以及一些其他的算法和技术,负载均衡器的路由方法能够有效的绕过瘫痪或过载的后端。这样运维人员在面对系统故障时,就可以更加从容的进行错误处理。

成本和性能收益:分布式系统的网络的一致性比较差。系统通常要跨越多个网络区域。同一区域内,网络资源通常是低售的;而在跨区域的情况下,超售则是常态(超售和低售的鉴别,是通过网卡上可消耗的带宽和路由器之间的可用带宽进行比对得出的结论)。智能的负载均衡会尽可能保证通信在同一区域内进行,从而提高性能(降低延迟)并降低总体系统成本(降低区域间的带宽和光纤需求)。

负载均衡器 vs 代理服务器

业内谈到网络负载均衡器,Load Balancer 以及 Proxy 这两个术语经常会同样对待,本文中也把这两个词条等价处理(卖弄一下:并非所有的代理都是负载均衡器,但是负载均衡是主流代理的首要功能)。

有人可能会问,有的负载均衡功能是作为客户端库的内置功能完成的,这种负载均衡器就不是代理服务器。这一话题本就容易混淆,这一质问更加让人糊涂。文中会详述这种负载均衡器的拓扑,这种嵌入的负载均衡方式只是代理的一种特例,应用通过内嵌的库来完成代理职能,跟典型的负载均衡器的区别仅在于进程内外而已,其整体抽象是一致的。

四层(连接/会话)负载均衡

业界在讨论负载均衡技术的时候,经常会分为两类:L4 和 L7。这一分类来源于 OSI 模型的四层和七层的定义。OSI 模型无法很好的描述负载均衡方案中的复杂性,一个四层负载均衡在完成传统的四层协议任务例如 UDP 和 TCP 之外,往往还会加入了其他层次的内容。例如一个四层的 TCP 负载均衡还支持 TLS 功能,这算七层负载均衡了么?

图 2:TCP 终端四层负载均衡

图 2 展示了一个传统的四层 TCP 负载均衡器。这个例子中,客户端向负载均衡器发起了一个 TCP 连接,负载均衡器 终结 了这一连接(也就是说直接响应了 SYN),接下来选择一个后端,然后创建了到后端的新的 TCP 连接(就是发起了新的 SYN)。图中的细节不需太过关注,后面的四层负载均衡章节会进行详细讨论。

本节的关键点是四层负载均衡一般只在四层的 TCP/UDP 进行操作。笼统的说,负载均衡器负责操作这些字节,保证同一会话的字节们只跟同一个后端打交道。四层负载均衡对通信中的应用细节是一无所知的。通信内容可以是 HTTP、Redis、MongoDB 或者任何应用协议。

七层(应用)负载均衡

四层负载均衡很简单,目前还在大面积使用。四层负载均衡有什么短处,以至于需要七层(应用)负载均衡呢?例如下面几个四层的案例:

两个 gRPC/HTTP2 客户端要连接到后端,所以通过四层负载均衡器来完成这一过程。

四层负载均衡器为每个接入的 TCP 连接创建一个外发的 TCP 连接,这样就有了两个接入、两个外发的连接。

然而客户端 A 的请求频率是每分钟 1 请求,而客户端 B 的频率是每秒钟 50 请求。

在上述场景中,为客户端 A 服务的后端,其负载水平仅相当于为客户端 B 服务的后端的约 1/3000 左右,这明显违背了负载均衡器的初衷。在所有多工、保持连接的协议中都会发生这样的情况(多工意思是在单一四层连接中并行发送应用请求;保持连接则意味着在没有活动请求的情况下,也不会关闭连接)。出于性能方面的考虑(创建连接的成本通常较高,尤其是当使用 TLS 对连接进行加密的情况下),所有的现代协议都包含这两个特性,所以随着时间的推移,四层负载均衡的负载不均的情况会越发明显。七层负载均衡能够解决这一问题。

图三:HTTP/2 七层终端负载均衡

图 3 描述了七层的 HTTP/2 负载均衡。这里客户端发起了对负载均衡的单个连接。负载均衡器连接到了两个后端。当客户端向负载均衡器发送两个 HTTP/2 流的时候,两个流会分别送往不同后端。这样多工客户端的大量不同的请求会被高效的分发给多个后端。这就是七层负载均衡对现代协议的重要性的来由(因为对应用流量的洞察能力,七层负载均衡还有很多其他好处,后面会详细描述)。

七层负载均衡和 OSI 模型

之前四层负载均衡章节中说过,用 OSI 模型来描述负载均衡是有困难的。OSI 描述的第七层,涵盖了负载均衡的多方面功能的臭显。比如对 HTTP 来说,有以下几个低级一些的层次:

可选的 TLS。网络界对 TLS 究竟应该属于 OSI 模型的哪一层素有争议。为讨论方便,我们放在七层。

物理的 HTTP 协议(HTTP/1或 HTTP/2)。

逻辑 HTTP 协议(Header、Body 和 Trailer)。

消息协议(gRPC、REST 等)。




一个成熟的的七层负载均衡器应该照顾到上面描述的每一层次。另一个七层负载均衡器可能只支持七层分类中的特性的一个子集。总而言之,七层负载均衡器的范畴包含了远超四层的为数众多的功能(例子中只提到了了 HTTP;Redis、Kafka、MongoDB 等也都是七层应用协议的例子,也都应受益于七层负载均衡)。

2
负载均衡器特性

下面简单汇总一下负载均衡器的高层功能。并非所有负载均衡器都提供了所有功能。

服务发现

服务发现就是负载均衡器用于决定可用后台列表的过程。这一功能的实现方式花样百出,下面举一些例子:

静态配置文件。

DNS。

Zookeeper、Etcd、Consul 等。

Envoy 的 统一数据平面 API。

健康检查

负载均衡器使用健康检查功能,来检测后端是否可用。健康检查有两种实现思路:

主动式:负载均衡器周期性的向后端发送 ping (例如一个发送到/healthcheck端点的 HTTP 请求),以此判断后端的健康情况。

被动式:负载均衡器通过对主数据流的分析来确定健康情况。比如一个四层负载均衡器,在发现连续三个连接错误的情况下,就会判定一个后端不可用;七层负载均衡可能会在连续三个 HTTP 503 响应之后判定这一后端为不健康状态。

负载均衡

是的,负载均衡器必须为负载做均衡。有了一系列的健康后端,如何选择后端来响应一个请求或者连接呢?负载均衡算法是一个活跃的研究领域,有 Round Robin 这样的简单办法,也有通过延迟和后端负载情况进行判断的复杂方案。 Power of 2 least request load balancing 一文,介绍了最流行的兼顾性能和简易的负载均衡算法之一。

随机选择两个后端,进一步选择其中负载较低的一个。

Session 粘连

在某些应用中有一个重要需求:同一会话的请求需要到达同一后端。对于缓存、临时复杂状态等场景来说这是很必要的。对于“同一会话”的定义有多种形式,可能包括 HTTP Cookie、客户端连接的属性以及其他属性。很多七层负载均衡器具有一些对会话粘连的支持。然而我认为会话粘连是一种天然易碎的情况(处理会话的后端可能会瘫痪),所以对于依赖会话的系统设计应该多加小心。

TLS 终端

TLS 这一话题,不管是边缘服务还是服务间通讯,都值得大书特书。因此很多七层负载均衡器在 TLS 处理方面都做了大量工作,其中包含终端、证书校验和绑定,使用 SNI 提供证书等功能。

观测性

我常说:“观测性、观测性、观测性。”,网络是一个天生不可靠的东西,负载均衡器应该提供状态、跟踪以及日志,协助运维人员甄别故障,从而进行修复。负载均衡器的检测输出差距很大。高级的负载均衡器供应包含数字统计、分布式跟中和自定义日志的大量输出。我认为增强的观测性并不是从天而降的,负载均衡器需要做出很多附加工作来完成这一任务。对性能造成的负面影响,相对于这一系列数据的好处来说,不值一提。

安全性和拒绝服务攻击防范

在边缘部署拓扑(后面会讲解)中,负载均衡器经常需要实现各种包含频率限制、认证以及 DoS 防范(例如 IP 地址的标记和辨识、Tarpitting等方式)等在内的安全功能。

配置和控制平面

负载均衡器应该是可配置的。在大规模部署中,这是一个重要的工作量。通常来说,用来配置负载均衡器的系统被称为“控制平面”,会有多种实现。拙作 Service Mesh Data Plan vs Control Plan 中对这一部分内容作了更深入的探讨。

还有很多

这部分只是对于负载均衡器的功能层面作了一些介绍。下面还会在七层负载均衡器方面做更多的深入讨论。

3
负载均衡器的拓扑分类

我们已经对负载均衡器的概念作了一些概括的介绍,四层和七层负载均衡器的区别,以及负载均衡器特性的汇总,接下来我们会针对分布式系统中的负载均衡器部署拓扑进行一些探讨(下面的每一种拓扑都是适用于四层和七层负载均衡器的)。

中间代理

图 4:中间代理负载均衡拓扑

图 4 描述的这种拓扑对多数读者来说都是最熟悉的。这一类别包括了 Cisco、Juniper、F5 等硬件产品;云软件解决方案例如 Amazone 的 ALB 和 NLB 以及 Google 的 Cloud Load Balancer,还有 HAProxy、NGINX 以及 Envoy 这样的纯软件自主方案。中间代理方案的优势在于对用户提供的简便性。

一般情况下用户只要通过 DNS 连接到负载均衡器即可,无需担心其他情况;弱势在于,负载均衡器存在单点失败的风险,同时也是可能的性能瓶颈。中间代理通常是一个不便运维的黑盒子。问题出现在哪里?是客户端还是物理网络?是中间代理还是后端?很难界定。

边缘代理

图 5:边缘代理负载均衡拓扑

图 5 实际上是中间代理的一种变体,这种负载均衡器可以通过 Internet 进行访问。在这一场景下,负载均衡器通常需要提供一些附加的 “API 网关”类功能,例如 TLS 终端、频率限制、认证以及流量路由等。优势和劣势跟中间服代理类似。在一个大的面向 Internet 的分布式系统中,边缘服务器通常是一个必要的组成部分。

客户端通常会使用某个不受服务提供商控制的网络库,通过 DNS 来访问这一系统(后面将会讨论的嵌入客户库或者 Sidecar 代理拓扑都不适合直接运行在客户端)。另外为了安全方面的考虑,为所有的面向 Internet 的流量使用单一的网关来提供入站流量是一个普遍要求。

嵌入式客户库

图 6:通过嵌入客户端库实现负载均衡

为了克服随中间代理而出现的单点失败以及性能问题,很多成熟架构把负载均衡直接植入如图 6 所示的客户端库中。不同的库所支持的功能差别很大,此类产品中最知名的功能丰富的包括 Finagle、Eureka/Ribbon/Hystrix 以及 gRPC(大致基于 Google 的一个称为 Stubby 的内部系统)。这种方式的好处是把所有负载均衡特性完全分布到每个客户端,从而避免了前面说到的单点失败和性能瓶颈。

这种做法的弱势也很明显,一个组织使用的所有语言,都需要实现这种客户端库。分布式架构下,这种多语言支持的要求会越来越多。这种环境里,每种语言的网络库实现造成的成本会让人望而却步。最后,在大的服务架构中进行库升级也是一个很大的挑战,而在生产环境中并行运行不同的版本,又会给运维造成更大压力。


结合上面的优劣势分析,可以知道,在能够限制编程语言使用,并克服升级痛苦的情况下,这种架构是可以获得成功的。

Sidecar 代理

图 7:Sidecar 代理实现负载均衡

嵌入式客户库的一个变体就是图 7 中的 Sidecar 代理拓扑。近年来,这一拓扑以 “Service Mesh” 的概念日益流行。Sidecar 代理背后的思路是,以进程间通信造成的些许延迟为代价,在无需顾虑编程语言锁定的情况下获得嵌入客户端库的各种优点。目前流行的 Sidecar 负载均衡包括 Envoy、NGINX、HAProxy 以及 Linkerd,我的两篇文章:Introducing Envoy 和 Service Mesh Data Plan vs Control Plan 对这种结构进行了更细致的描写。

不同负载均衡器拓扑的总结和优劣势

中间代理拓扑是最简单的最典型的方式。他的弱点在于:故障单点、伸缩瓶颈以及黑箱操作。

边缘代理拓扑和中间代理类似,通常无法忽略。

嵌入客户端库的方式提供了最好的性能和伸缩性,不过面向多种语言的开发,和升级所有服务的库都是很大的挑战。

Sidecar 代理拓扑比嵌入式客户端库要弱,但也避免了这种方式的两大难点。

总的来说,我认为在服务对服务的情况下,Sidecar 代理拓扑(Service Mesh)会逐渐代替所有其他拓扑形式。为了处理进入 Service Mesh 之前的流量,边缘代理拓扑会长期存在。

4
四层负载均衡的现状

四层负载均衡器还有用么?

本文已经谈论了很多七层负载均衡器对现代协议的好处,后面还会谈到七层负载均衡的功能细节。这是否意味着四层负载均衡器无需存在了?不是的。虽然我认为最终七层负载均衡会完全在服务对服务的场景中取代四层负载均衡器,但四层负载均衡器对边缘通信还是非常有意义的,这是因为所有现代的大型分布式架构都是用了两层的四层/七层负载均衡架构来处理互联网流量。在七层负载均衡器之前部署独立的四层负载均衡器的好处是:

七层负载均衡器要在应用层面进行更多的精密分析、变换以及路由工作,对于原始流量(每秒数据包或每秒字节数)的负载,其能力要弱于优化过的四层负载均衡器。这一现实使得四层负载均衡器更便于应对拒绝服务攻击(例如 SYN flood、通用包 flood 攻击等)。

相对于四层负载均衡器,七层负载均衡器的开发更加活跃,部署更加频繁,也会有更多 Bug。有了前置的四层负载均衡器,就可以在七层负载均衡器升级期间进行健康检查和排空,现代四层负载均衡器通常使用 BGP 和 ECMP(后续章节会详细讲解),七层负载均衡的部署通常会较为简单。最后因为七层负载均衡器相对来说复杂度较高,因此也更容易出现问题,有了前端的四层负载均衡,就可以在出现问题的时候利用路由功能绕过故障节点,提高系统的总体稳定性。

下文中我会讲到集中不同设计的中间/边缘四层负载均衡器。后面提到的设计通常是无法用在客户库或 Sidecar 拓扑中的。

TCP/UDP 终端负载均衡器

图 8:四层终端负载均衡器
还在应用的第一种四层负载均衡器是图 8中的终端负载均衡器。这和我们介绍四层负载均衡的时候讲到的内容是一致的。这种类型的负载均衡器中,使用了两个的独立的 TCP 连接:一个用于客户端和负载均衡器之间;另一个用在负载均衡器和后端之间。

四层终端负载均衡器还有两个原因:

实现相对简单。

靠近客户端的连接终端对性能有显著影响。尤其是如果客户使用有损网络(例如蜂窝网)的话,在进入稳定的有线传输到最终目的之前,是容易发生重传的。换句话说,这种负载均衡器适用于在存在点(Point of Presence )场景下的原始 TCP 连接。

TCP/UDP 透传负载均衡器

图 9:透传负载均衡器

四层负载均衡器的另一种类型就是图 9所说的透传负载均衡器。这种类型的负载均衡过程中,TCP连接没有被负载均衡器终结,每个链接的数据包,在经过连接分析和网络地址转换(NAT)过程之后,都被转发给一个选中的后端。首先让我们定义一下连接跟踪和 NAT:

连接跟踪:跟踪全部活动 TCP 连接的过程。这里包括很多内容,例如握手是否完成,是否收到 FIN,连接发呆了多久,这个连接转发给哪一个后端等。

NAT:是使用连接跟踪数据,来更改数据包的 IP/端口信息使之穿过负载均衡器的过程。

有了连接跟踪和 NAT,负载均衡器就能把客户端的 TCP 流量几乎原封不动的的转发给后端。例如客户端同1.2.3.4:80进行通信,选中的后端是10.0.0.2:9000。客户端的 TCP 数据包会到达位于1.2.3.4:80的负载均衡器。负载均衡器会把目标 IP 和端口替换为10.0.0.2:9000;同时还会把源 IP 替换为负载均衡器的 IP。当后端响应 TCP 连接时,数据包就会返回给负载均衡器,负载均衡器中的链接跟踪和 NAT 再次发挥作用,反向送回数据包。

为什么会使用这一种负载均衡器,而不是前面提到的终端型呢?

性能和资源消耗:透传型的负载均衡器没有终结 TCP 连接,无需缓存任何的 TCP 连接窗口。每个连接的状态存储非常小,通常使用高效的哈希表查询即可。正因如此,相对终端负载均衡器来说,透传型负载均衡器能够处理更大数量的活动链接,单位时间内处理更多的数据包。

允许后端进行拥塞控制:TCP 拥塞控制 是一种机制,让 Internete 端点对外发数据进行流量控制,防止超量使用带宽和缓冲。

为直接服务器返回(Direct Server Return = DSR)做基线,以及四层负载均衡集群:透传负载均衡也是高级四层负载均衡(例如后面将要说到的 DSR 和使用分布式一致性哈希的集群)的基础。

Direct Server Return (DSR)

图 10:四层 DSR

图 10展示的就是 DSR 负载均衡。DSR 构建在前文提到的透传负载均衡器的基础之上。DSR 是一种优化方案,只有入站/请求数据包通过负载均衡;出站/响应数据包绕过负载均衡器直接返回给客户端。使用 DSR 方案的有趣之处在于,很多负载的响应比请求数据量大很多(比如典型的 HTTP 请求和响应)。假设 10% 的流量是请求,另外 90% 是响应,如果使用了 DSR 负载均衡,仅需要 1/10 的容量就能够满足系统需要。从前的负载均衡非常昂贵,这一方案能够显著降低系统成本并提高可靠性(更少就是更好)。DSR 负载均衡器用下面的方式扩展了透传负载均衡的概念:

由于响应包不再经过负载均衡器,所以连接跟踪仅有部分数据,负载均衡器无法知道完整的 TCP 连接状态。然而还是可以通过对客户数据包的观察,对发呆超时的情况来推断具体状态。

负载均衡器通常使用 GRE 来封装 IP 包,并从负载均衡器发送到后端。这样当后端接收到封装后的数据包,可以解包并获得客户端的端口和地址。这样后端就能直接跨过负载均衡器直接发送响应包给客户端了。

DSR 负载均衡器的一个重要部分就是:后端部分的参与了负载均衡过程。后端需要合理的配置 GRE 隧道,并且需要根据网络的低级细节来配置自己的连接跟踪以及 NAT 等。

注意不管是 DSR 还是透传负载均衡器,其中的连接跟踪、NAT、GRE 等组成部分都有很多不同设计方式。这些设置从负载均衡器到后端都会涉及。这部分内容超出了本文的范围,就不再深入进行了。

使用高可用配对方式实现容错

图 11:使用 HA 对和连接跟踪实现容错

到现在,我们要考虑四层负载均衡的容错设计了。不管是 DSR 还是透传负载均衡都需要一定数量的链接跟踪和状态数据存储在负载均衡器中。负载均衡器宕机了会怎样?——所有经过这一负载均衡器的连接都会断掉。可能对应用产生显著影响。

历史上,四层负载均衡器是一种从典型供应商(Cisco、Juniper、F5 等)采购的硬件。这些设备非常昂贵,能够处理大量通信。为了防止单点失败导致的所有连接中断,引发应用故障,负载均衡器通常会使用高可用配对的方式进行部署,如图 11 所示。典型的高可用负载均衡器配置会满足如下设计:

一对高可用边缘路由器提供一系列的虚拟 IP(VIP)。这些边缘路由器使用边界网关协议(BGP)来发布虚拟 IP。主要边缘路由器的 BGP 优先级高于备用边缘路由器,所以正常情况下他会处理所有流量(BGP 是一个超级复杂的协议;为了行文方便,可以理解 BGP 是一种机制,这种机制让网络设备可以宣称自身能够处理来自其他网络设备的流量,并且每个连接都会有一个权重,从而影响连接的通信)。

类似的,主要四层负载均衡向 BGP 权重较高的边缘路由器宣告可用,所以在通常情况下,他会处理所有流量。

两个边缘路由器和两个负载均衡器是交叉连接的,这意味着如果一个边缘路由器或者一个负载均衡器宕机,或者因为某些原因 BGP 宣布失效,备用设备就会接入,承载所有流量。

上面的设置是目前很多互联网上的高流量应用还在持续使用的方式,但是这种方案有一些副作用:

VIP 必须通过高可用负载均衡器对流量进行正确的分配。如果单一 VIP 的容量超过了 HA 对,则 VIP 需要分割为多个 VIP。

系统资源使用率很低。通常会有一半的容量在闲置。过去的负载均衡器非常昂贵,所以这一闲置成本也是很高的。

现代分布式系统设计要求比主备模式更好的容错设计。例如一个系统需要在多个同时出现故障的情况下保持运行。高可用负载均衡对如果遭遇同时故障,就会导致完全瘫痪。

供应商提供的硬件设备价格昂贵,会导致对特定厂商的依赖。使用支持水平扩展的软件方案对商业硬件设施进行替换,是目前普遍存在的迫切需要。

使用分布式一致性哈希进行容错和伸缩

图 12:四层负载均衡器和一致哈希实现容错和伸缩

前文介绍了通过高可用配对的方式来进行负载均衡器的容错设置,以及随之而来的问题。千禧年初,一些大的互联网基础设施提供商开始设计和部署新的图 12 模式的并行四层负载均衡系统。这类系统的目标是:

解决使用成对 HA 模式设计的负载均衡方案带来的所有问题。

从厂商专属的专利硬件模式的负载均衡器中迁移出来,使用标准服务器和网卡配合商业软件方案进行替代。

四层负载均衡器的设计是 fault tolerance and scaling via clustering and distributed consistent hashing 的最佳引用,具体工作模式是:

N 个边缘路由器在同一 BGP 权重上,声明所有的 任播 VIP。使用 ECMP(等价多路径路由) 来保证所有单一 Flow 能够到达同一个边缘路由器。一个 Flow 通常是一个由源 IP/端口和目的 IP/端口 构成的元组。(简单说,ECMP 是一个在使用一致性哈希连接的独立加权网络上分发数据包的方式)。边缘路由器并不在意哪些数据包去了哪里。一般会倾向于把来自于一个 Flow 所有数据包发送给同一套连接,以此避免乱序包导致的性能损失。

N 个四层负载均衡器向边缘路由器在同一个 BGP 权重上声明所有的 VIP。再次借助 ECMP,边缘路由器会选择为同一个 Flow 选择同一个负载均衡器。

每个四层负载均衡器会进行部分的连接跟踪,为这一 Flow 使用一致性哈希选择一个后端。从负载均衡器到后端的数据包会使用 GRE 进行封装。

接下来使用 DSR 将相应包直接从后端通过边缘路由器发送会客户端。

四层负载均衡器使用的一致性哈希算法是一个活跃的研究领域,其中涉及合理分配、减小延迟、后端变更成本以及最小化内存开支等各方面要素。这方面的完整讨论也超出了本文范围。

接下来看看这种设计如何克服 HA 配对方式的缺点:

新的边缘路由器和负载均衡器可以按需加入。一致性哈希会在各个层次上使用,在加入新机器的时候,尽可能降低受影响的 Flow 数量。

在保持对突发消耗的支持能力以及容错能力的同时,可以提高资源的使用率。

边缘路由器和负载均衡都可以使用使用普通硬件,仅是传统硬件负载均衡成本的几分之一(下文会进一步说明)。

行文至此,有读者可能会问:“为什么不让边缘路由器直接通过 ECMP 和后端进行通信?为什么我们还需要负载均衡器?”。答案是 DoS 防范以及后端运维难度。如果没有负载均衡器支持,每个后端都需要加入 BGP,而且难于进行滚动更新。

所有的现代四层负载均衡系统都在向着这一方案(或其变体)迁移。两个最为公众所知的例子就是 Google 的 Maglev 以及 Amazon 的 Network Load Balancer (NLB)。目前还没有任何开源负载均衡器实现了这一设计,然而据我所知,有公司要在 2018 年发布一个这样的产品。我很期待他的出现,这一产品将会填补开源网络组件的重要空白。

当前七层负载均衡的技术状态

Current state of the art in L7 load balancing The proxy wars in tech currently is quite literally the proxy wars. Or the "war of the proxies". Nginx plus, HAProxy, linkerd, Envoy all quite literally killing it. And proxy-as-a-service/routing-as-a-service SaaS vendors raising the bar as well. Very interesting times!

是的,的确是这样。近几年我们看到七层负载均衡/代理技术的开发工作开始复兴。随着分布式微服务系统的不断推进,这方面也会不断进步。从基础上看,目前对于靠不住的网络的依赖越发严重,带来更高的运维难度。从长远看,自动伸缩、容器编排等技术的大量使用,意味着静态 IP、静态文件的时代已经过去了。系统不仅更多的使用网络,而且更加动态,需要新的负载均衡功能。在本节中我们简单归纳一下现在七层负载均衡器的功能。

协议支持

现代七层负载均衡器加入了很多不同协议的显式支持。负载均衡器对应用通讯认识越多,就越能做好监控输出、高级负载均衡和路由等功能。例如目前 Envoy 显式的支持七层协议解析和路由的范围包括 HTTP/1、HTTP/2、gRPC、Redis、MongoDB 以及 DynamoDB。包括 MySQL 和 Kafka 在内的更多协议会逐渐添加进来。

动态配置

如上文所述,分布式系统的大行其道,需要有动态配置能力来提高系统的动态和控制能力。Istio就是一个这种系统的例子。请参考 Service Mesh Data Plan vs Control Plan 来获取更多这方面的内容。

高级负载均衡

七层负载均衡器一般都有内置的高级负载均衡支持,例如超时、重试、频率控制、断路器、Shadow、缓冲、基于内容的路由等。

可观测性

上文中也提到过,负载均衡的一个常见功能,越来越多的动态系统被部署,调试难度也水涨船高。健壮的协议规范观测输出可能是未来七层负载均衡器要提供的最重要功能之一。统计数字、分布式跟踪以及可以定义日志的输出,目前已经成为对器层负载均衡解决方案的必须要求。

扩展性

现代七层负载均衡器需要能够简单的加入定制功能。这一功能可以通过编写可插接过滤器,并载入到负载均衡器的方式来实现。很多负载均衡器还支持脚本扩展,例如 Lua。

容错

在讲四层负载均衡的容错时颇费了一番口舌。七层负载均衡的容错又怎样呢?一般来说我们认为七层负载均衡器(的工作负载)是无状态的可抛弃的。使用普通软件就能够简单的对七层负载均衡器进行水平扩展。另外七层负载均衡的流量处理和状态跟踪的复杂度要远超四层。设置七层负载均衡器的 HA 配对在技术上是可行的,但会非常繁杂。

总的说来,不管是四层还是七层的负载均衡,业界都在尝试走出 HA 配对模式,转向一致性哈希为基础的水平扩展方式。

更多

七层负载均衡器正在高速发展。可以参考 Envoy 架构概览。

5
全局负载均衡和中心控制平面

图 13:全局负载均衡

未来会有越来越多的独立负载均衡器以商品设备的面目呈现。我认为真正的创新和商业机会来自于控制平面。图 13展示了一个全局负载均衡系统。在本例中有一些不同的东西:

每个 Sidecar 代理和三个不同区域的后端进行通信。

如图,90% 的流量会被发送到 C 区,A B 两区分别得到 5%。

Sidecar 代理和后端都会周期性的向全局负载均衡器进行汇报。这样全局负载均衡器就可以根据延迟、成本、负载、失败率等数据进行精密决策。

全局负载均衡周期性的使用当前的路由信息配置每个 Sidecar 代理。

全局负载均衡能做一些单一负载均衡器做不到的事情,例如:

对分区故障的自动检测和路由绕行。

应用全局的安全和路由策略。

使用机器学习和神经网络,对异常流量进行检测和防范,包括分布式拒绝服务攻击。

提供中央界面和可视化支持,让工程师能够以聚合的角度,对整个分布式系统进行监控和运维。

全局负载均衡器要成为现实,他的数据平面必须具有强大的动态配置能力。请参考我的博客:Envoy's universal data plane API,以及 Service Mesh Data Plan vs Control Plan 。

6
从硬件到软件的变革

这里只是简要的提到了硬件和软件的问题,主要聚焦在四层负载均衡高可用方面的历史问题。这一领域的业界趋势又如何呢?

这一推虽说略显浮夸,但却很好的描述了技术趋势:

历史上的负载均衡器和路由器都曾经是昂贵的专属硬件

逐渐的,多数三层四层网络设备都被替换为通用服务器硬件和网卡,以及基于 IPVS、DPDK 和 fd.io之类的框架的特定软件方案。一个现代的成本低于 $5k 的数据中心,运行 Linux 和自定义的基于 DPDK 的 user-space 应用,能够轻松用超小数据包跑满 80Gbps 的网络。另外廉价的基于 ASICs 的基础路由器/交换机也能够完成 ECMP 路由工作,并能支撑和通用路由器同级别的带宽和包速率。

Nginx、HAProxy 以及 Envoy 这样的七层软负载均衡,也正快速发展,逐步进入过去由 F5 这样的厂商的专属领域。此外,七层负载均衡器正激进的向通用软件方案的方向迈进。

同时,主要云提供商推动的 IaaS、CaaS 以及 FaaS 潮流,使得只有一小部分人需要理解物理网络(这属于黑科技,以及“我们不再需要深入了解”的范围了)。

7
结论,以及负载均衡器的未来

综上所述,本文的主旨:

负载均衡器是现代分布式系统的关键组件。

有两种负载均衡器:四层和七层。

四层和七层负载均衡器都与现代架构相关。

四层负载均衡器正在朝着基于一致性哈希的水平扩展方案的方向进行迁移。

由于动态微服务架构的成长,七层负载均衡器得以快速发展。

控制平面和数据平面的拆分,和全局负载均衡,是负载均衡的未来发展方向和机会来源。

业界正激进的迈向标准硬件和软件的开源解决方案。我相信传统的像 F5 这样的负载均衡厂商会被开源软件和云供应商取代。传统的路由器、交换机厂商,例如 Arista/Cumulus 等,短期内会有更好的发展,但最终也会被共有云提供商及其自研物理网络所取代。

总的说来,我认为这是计算器网络的奇迹年代。多数系统开始向开源和软件方向转变,极大的提高了迭代速度。未来,分布式系统又向无服务器计算进军,底层网络和负载均衡系统的复杂性也势必齐头并进,水涨船高。

原文:https://blog.envoyproxy.io/int ... 80236

微服务2017年度报告出炉:4大客户画像,15%传统企业已领跑

杨y 发表了文章 • 0 个评论 • 140 次浏览 • 2018-01-18 00:29 • 来自相关话题

开篇:

如果在诸多热门云计算技术中,诸如容器、微服务、DevOps、OpenStack 等,找出一个最火的方向,那么非微服务莫属。尽管话题炙手可热,但对传统行业来说,微服务落地和方法论目前处于起步阶段。

本报告于2017年11月份展开,从驱动因素、落地现状、和容器关系、架构体系、未来趋势和落地方法论等方面对微服务进行了分析。希望能够为传统企业微服务决策、规划和实施提供依据和解决办法。

一、驱动因素

传统行业对IT效率的变革需求是微服务成长土壤,业务模式创新重塑导致系统更新频繁、应用复杂度急剧升高,传统架构不堪重负。

微服务架构具有明显的好处,尤其是在应对复杂业务系统的多变需求方面。在本次调研企业中,每个月都要进行业务系统更新的比例占63%,只有不到20%的企业半年以上更新一次系统。













加快互联网+步伐成为许多传统企业的必然选择。业务场景、用户习惯和行为在迅速变化,许多传统行业线上业务出现急速增长。

比如金融行业的移动支付、互联网理财等,汽车制造行业的营销、电商、售后服务等线上业务比例迅速提高。IT团队业务开发、迭代都以每月、甚至每周来计,需要7*24小时响应,这些给系统开发和运维带来极大挑战。

在IT对业务的响应和支撑方面,不同行业所面临的困扰略有不同,但总体差异不明显。调研显示,系统支撑方面排在前四的难题分别为:系统复杂性越来越高(28%),运维管理复杂度高,打造一支全栈运维团队困难(26%),线上访问压力大(19%),设备采购维护成本高(19%)。







在传统单体或SOA架构下,应用如果频繁升级更新,开发团队非常痛苦。企业的业务应用经过多年IT建设,系统非常庞大,要改动其中任何一小部分,都需要重新部署整个应用,敏捷开发和快速交付无从谈起。

传统企业在长期的IT建设过程中,通常大量使用外包团队,这导致采用的技术栈之间差异较大,统一管控和运维要求更高。需要运维7*24小时全天候值守、在线升级,并快速响应。

在此时脱颖而出的微服务技术,面对上述困惑几乎浑身优点:独立开发、独立部署、独立发布,去中心化管理,支持高并发高可用,支持丰富技术栈,企业可以根据需要灵活技术选型。

二、微服务落地现状

1、微服务客户画像

微服务架构在企业的使用情况可以分为四个层次:初级使用者、轻度使用者、中度使用者、以及重度使用者。初级使用者基本是传统架构,独立部署需求不突出,技术堆栈不成熟,需要较长的培育和成长期。轻度使用的企业边缘业务系统开始使用Spring Boot 或Spring Cloud等框架,但组件的使用尚不熟练。

中度使用者为使用Dubbo或Spring cloud时间较长,但还没有做周边配套的工具链。重度使用者是那些走在微服务架构改造前沿,具备微服务规划和体系,有自己研发实力的企业,通常是以技术见长的大型互联网公司。

2、15% 左右的调研企业引入了SpringCloud、Dubbo等微服务主流开发框架

此次调研中,6%的企业已经部分引入了Spring Cloud 开发框架,Spring Cloud 也被开发者认为是最好的开发框架。另外,9%的受访企业采用了 Dubbo 等其他微服务框架,也就是说引入了或考虑引入微服务架构的企业达15%。







此外,还有51%以上的企业在考虑往云原生方向转型。这是由于企业数字化转型背景下,IT要更好适应线上业务趋势的必然要求。加上国家政策层面对云服务的支持,传统企业云化是大势所趋。

* 3、微服务四大技术优势受青睐*

从IT技术发展趋势看,无论硬件、软件、还是基础架构都在朝着轻量化的方向发展。微服务通过化整为零的概念,将复杂的IT部署分解成更小、更独立的微服务。 相对传统的建设方法,传统企业更看重微服务如下四方面的优势:技术选型灵活,更轻松采用新架构和语言(28%)降低系统内部服务冗余,提升开发效率(27%)独立部署(22%)更好的容错机制(20%)







在涉及复杂项目时,和单体架构的对比中,微服务从多个角度显示出了压倒性的优势。

4、制造业开始发力、金融小试牛刀

这里所说制造业,是大制造的概念,包括制造、汽车、大型制造以及航空业等。这些行业往引入Spring Cloud、Dubbo等微服务开发框架的企业占比超过15%。制造业开始初步尝试微服务架构。 能看出制造业向“智造”转型的影响,今天的制造业结合了物联网、传感器、云计算、大数据等技术,人工智能技术正在工业、汽车驾驶等领域应用。大量新兴业务场景出现,服务变得复杂,产业的弯道超车带来了明显的微服务需求。
 







其次,需求明显的为金融行业,包括银行、保险、证券等。尤其是一些国有银行、股份制银行以及城商行等大行都走在架构改造的前列。在自己的创新业务,如手机银行、微信银行、互联网理财等业务上试水微服务架构。在核心业务系统方面,则相当谨慎。一方面是由于监管和政策的原因,另一方面,银行开发体系庞大,IT架构变革将是一件非常复杂的事情。

5、微服务推进障碍

微服务不是完美架构,会带来系统的各种复杂度,以及运维要求更高等诸多难点 微服务并不是一项横空出世的技术,事实上MicroService的概念已经诞生多年。除了组件和技术不成熟,企业业务模式不急迫的因素外,微服务本身也有自己的劣势。







本次调研,有近一半的企业会谈到对微服务的顾虑。比如部署以后的复杂度,后期运维管理的不友好等等。对于团队来说,搭建微服务架构上手难,运维效率低,运维成本高。另外,还可能带来团队之间沟通上的冲突,微服务需要与DevOps同步推进。微服务被分割成一个个独立的业务模块后,服务间通信接口设计非常重要。如何科学地将系统部署到服务器上,保证各个服务高效运行,更是难点。

微服务推进过程中有许多障碍。对微服务自身复杂度的担忧、缺少具备相关经验的专家、难以招募专业人才和使用相关工具是三个最普遍的障碍。其中对微服务复杂度的顾虑,排名前三的是运维要求和成本高,分布式架构的网络延迟、容错等挑战,以及较强的部署依赖性。

三、Docker与微服务

在接受调研的企业中,2017年在生产环境中采用Docker的比例为9%,测试环境使用达22%。而且规模越大的企业,尤其是服务器规模在500台以上的,是Docker容器的主要采用者。另外,正在考虑评估中的占到被调研企业的一半以上。企业的关注度急剧升高,Docker使用正在快速普及。





 

容器和微服务相辅相成,两大技术成熟的时间点非常契合。容器技术的成熟为微服务提供了得天独厚的客观条件。轻量化的容器是微服务的最佳运行环境,微服务应用只有在容器环境下才能保障运维效率的提升。同时,微服务应用架构对外在组件的管理会变得困难,需要用容器平台去管理中间件,才能发挥出更大价值。

四、微服务化是一个体系,从架构、工具到团队协同

1、企业微服务架构改造需要包括周边配套工具链在内的一整套微服务体系

采用微服务架构改造应用系统,不仅仅是选择开发框架本身,还要建设一套完整的体系架构。既要实现应用模块之间的解耦,还要实现统一管理。

微服务化体系,包括开发框架、以及周边配套工具链和组件,比如服务注册、服务发现、API网关、负载均衡、服务治理、配置中心、安全管理、与容器的结合、监控管理等等。一整套的体系建设是微服务真正的难点所在。

落地过程中,受访企业关注的功能包括,API网关(33%)、服务治理(27%)、配置中心(21%)、分布式任务调度(17%)、应用监控与报警(11%)、高并发(7%)等。这些组件可以根据自身的业务特性选择使用。







2、微服务落地方法论:咨询+产品工具+实施

在IT建设中,企业都希望将开发人员的精力放在自身业务系统的开发上,而工具的整合和使用则主要借助外部供应商的力量来做。软件外包商都有自己的发展历程,迅速改变技术架构不太现实。

另外,传统企业都有大量原有IT系统,掉头和转向不可能丢掉历史包袱,全部推翻重新建设。因此,企业一方面有架构之痛,另一方面不得不总是在业务系统快速上线和新架构选择之间平衡。

对于企业来说,最实际的微服务落地路径是,首先纳入微服务咨询,引入外部行业技术专家角色,站在企业架构的总体高度,帮助企业进行微服务体系规划,落地roadmap,然后借助一些产品和工具进行落地实施。

在本次调研中,有的企业鉴于微服务的优势和业务快速变化的需要,会在新项目建设时直接选择微服务架构进行开发,落地方法也不例外。

3、企业践行微服务的三种类型

目前微服务落地的企业可以分为:温柔型的变革者、业务倒逼型的强硬者、观望型的探索者。

具体来说,温柔的变革者从边缘非核心业务探索尝试新兴技术。渐进式实施、创新灵活多变业务是这类型客户微服务切入的关键词。也是大部分传统企业在切入微服务时,选择的路径。

本次参与调研的企业多是如此,在切入微服务时,选择了诸如测试流程、API网关、开发平台升级、测试环境快速部署等非核心业务进行技术验证。







业务倒逼型是那些企业核心业务系统在日常支撑中承受着巨大压力,必须进行架构改造,否则业务运转举步维艰。观望型的探索者,是那些出于业务考量,要看到行业标杆案例,明确收益和价值,以及技术风险和可靠性充分把握的情况下,才会投入资源开始改造。

4.微服务落地需要从上到下推动和密切团队协同

微服务应用的构建依赖组织结构的变化,它按照业务,而不是技术来划分组织,在推进过程中会受到从上到下的压力,因此必须有决策层的支持和推动。同时,需要团队更好的协同,小团队作战,打破团队间的高墙,减少沟通成本。上了微服务的受访企业对搭建一支敏捷团队都感受很迫切。

五、Service Mesh下一代微服务抢滩登陆

预计两年内服务网格技术将呈现爆发之势

本次的受访者中,有42%表示听说过 ServiceMesh 这一新兴技术理念,但只有6%的受访者对该技术有过一些研究。







微服务带来的复杂度让企业头疼,尤其是服务间通信,如何保证服务间通信的端到端性能和可靠性,催生了下一代微服务Service mesh。2017年,ServiceMesh 经过技术拥趸、技术社区和媒体的反复布道,迅速被业界了解。

Service Mesh 是服务间通信层,可以提供安全、快速、可靠的服务间通讯。在过去的一年中,Service Mesh 已经成为微服务技术栈里的一个关键组件,被誉为“下一代微服务”。

Conduit、Istio 等Service Mesh技术在市场上已形成激烈的竞争,国内外企业开始纷纷站队。国外,一些有高负载业务流量的公司都在他们的生产应用里加入了Service Mesh。国内前沿技术公司开始围绕SpringCloud等开发体系,为客户提供成熟的解决方案和工具产品。同时,探索基于 ServiceMesh 的新方案,积极拥抱Istio/Conduit。

当然对于传统企业来说,技术的先进性是为了保障业务需求的快速变化和发展,而不是一味追求新兴。受访企业表示,一方面会主动关注新技术的最新动向,另一方面在考虑落地时,也要关注新技术的可靠性和有例可循,有无业界最佳实践背书。

六、结论

微服务的核心使命是简化开发,提高IT系统对业务的支撑能力。通过本次调研,我们可以得出如下一些结论:

1.传统行业新兴业务对IT效率的变革需求,业务模式创新重塑要求IT快速响应,是今天微服务炙手可热的主要驱动因素。从目前微服务落地的状态预估有两年左右的培育和成长期。







评估一家企业是否需要上微服务,主要考察这五大关键要素:数据量和业务复杂度,团队规模,应对业务流量变化,是否需要足够的容错容灾,以及功能重复度和差错成本。

2. 实施微服务的理想技术条件包括:进程隔离、数据库表隔离,以及通过公开接口访问。







3. 微服务架构在企业的使用可以分为四个层次:初级使用者、轻度使用者、中度使用者,以及重度使用者。







以技术见长的大型互联网公司首先引领了微服务的风潮,国内制造、金融等大型龙头企业中也有佼佼者开始规划微服务体系,且具备较强的研发实力。大部分企业还处在初步尝试,不成体系,寻找技术和专家力量探讨解决方案的阶段。

4.微服务和容器共生:容器和微服务相辅相成,天生一对。Docker的成熟,让微服务推广和落地更加可靠、方便。随着Docker和微服务架构组件等相关技术的逐步成熟,微服务架构将逐步落地传统企业。 







5.微服务落地方法论:微服务主要用来解决系统的复杂性问题,企业客户对于如何实施微服务并不清晰,同时有诸多顾虑。受企业客户青睐的落地方法是:微服务咨询+产品工具+实施。 







6.微服务落地策略:微服务正成为许多企业构建应用时的首选。微服务并不缺乏受众,有的企业将微服务用于新应用开发,有的关注将单体应用迁移到微服务架构。微服务改造循序渐进,快速演化只会适得其反。另外,落地过程中注意开发和运维部门的协同,进行组织内管理创新。 







关于调研对象

本次调研我们总计收到了来自182家企业受访者的调研问卷,并现场调研部分受访企业。覆盖制造/航空、金融、互联网、地产、交通物流和零售等行业,受访者包括CIO、CTO等IT高管,及开发、基础架构部门IT人员。

参考资料: 
1.The State of Microservices Survey 2017 – Eight Trends You Need to Know 
https://dzone.com/articles/the ... trend 
2、Microservices: Breaking Down the Monolith 
https://dzone.com/guides/micro ... olith 
3.微服务企业级落地将会带来哪些转变? 
http://mp.weixin.qq.com/s/3LkU4OwpgSPdFFY5__dheQ 
4.深度剖析微服务架构的九大特征 
http://developer.51cto.com/art/201608/516401.htm 查看全部
开篇:

如果在诸多热门云计算技术中,诸如容器、微服务、DevOps、OpenStack 等,找出一个最火的方向,那么非微服务莫属。尽管话题炙手可热,但对传统行业来说,微服务落地和方法论目前处于起步阶段。

本报告于2017年11月份展开,从驱动因素、落地现状、和容器关系、架构体系、未来趋势和落地方法论等方面对微服务进行了分析。希望能够为传统企业微服务决策、规划和实施提供依据和解决办法。

一、驱动因素

传统行业对IT效率的变革需求是微服务成长土壤,业务模式创新重塑导致系统更新频繁、应用复杂度急剧升高,传统架构不堪重负。

微服务架构具有明显的好处,尤其是在应对复杂业务系统的多变需求方面。在本次调研企业中,每个月都要进行业务系统更新的比例占63%,只有不到20%的企业半年以上更新一次系统。


1.jpg


2.jpg



加快互联网+步伐成为许多传统企业的必然选择。业务场景、用户习惯和行为在迅速变化,许多传统行业线上业务出现急速增长。

比如金融行业的移动支付、互联网理财等,汽车制造行业的营销、电商、售后服务等线上业务比例迅速提高。IT团队业务开发、迭代都以每月、甚至每周来计,需要7*24小时响应,这些给系统开发和运维带来极大挑战。

在IT对业务的响应和支撑方面,不同行业所面临的困扰略有不同,但总体差异不明显。调研显示,系统支撑方面排在前四的难题分别为:系统复杂性越来越高(28%),运维管理复杂度高,打造一支全栈运维团队困难(26%),线上访问压力大(19%),设备采购维护成本高(19%)。

3.jpg



在传统单体或SOA架构下,应用如果频繁升级更新,开发团队非常痛苦。企业的业务应用经过多年IT建设,系统非常庞大,要改动其中任何一小部分,都需要重新部署整个应用,敏捷开发和快速交付无从谈起。

传统企业在长期的IT建设过程中,通常大量使用外包团队,这导致采用的技术栈之间差异较大,统一管控和运维要求更高。需要运维7*24小时全天候值守、在线升级,并快速响应。

在此时脱颖而出的微服务技术,面对上述困惑几乎浑身优点:独立开发、独立部署、独立发布,去中心化管理,支持高并发高可用,支持丰富技术栈,企业可以根据需要灵活技术选型。

二、微服务落地现状

1、微服务客户画像


微服务架构在企业的使用情况可以分为四个层次:初级使用者、轻度使用者、中度使用者、以及重度使用者。初级使用者基本是传统架构,独立部署需求不突出,技术堆栈不成熟,需要较长的培育和成长期。轻度使用的企业边缘业务系统开始使用Spring Boot 或Spring Cloud等框架,但组件的使用尚不熟练。

中度使用者为使用Dubbo或Spring cloud时间较长,但还没有做周边配套的工具链。重度使用者是那些走在微服务架构改造前沿,具备微服务规划和体系,有自己研发实力的企业,通常是以技术见长的大型互联网公司。

2、15% 左右的调研企业引入了SpringCloud、Dubbo等微服务主流开发框架

此次调研中,6%的企业已经部分引入了Spring Cloud 开发框架,Spring Cloud 也被开发者认为是最好的开发框架。另外,9%的受访企业采用了 Dubbo 等其他微服务框架,也就是说引入了或考虑引入微服务架构的企业达15%。

image005.jpg



此外,还有51%以上的企业在考虑往云原生方向转型。这是由于企业数字化转型背景下,IT要更好适应线上业务趋势的必然要求。加上国家政策层面对云服务的支持,传统企业云化是大势所趋。

* 3、微服务四大技术优势受青睐*

从IT技术发展趋势看,无论硬件、软件、还是基础架构都在朝着轻量化的方向发展。微服务通过化整为零的概念,将复杂的IT部署分解成更小、更独立的微服务。 相对传统的建设方法,传统企业更看重微服务如下四方面的优势:技术选型灵活,更轻松采用新架构和语言(28%)降低系统内部服务冗余,提升开发效率(27%)独立部署(22%)更好的容错机制(20%)


image006.jpg


在涉及复杂项目时,和单体架构的对比中,微服务从多个角度显示出了压倒性的优势。

4、制造业开始发力、金融小试牛刀

这里所说制造业,是大制造的概念,包括制造、汽车、大型制造以及航空业等。这些行业往引入Spring Cloud、Dubbo等微服务开发框架的企业占比超过15%。制造业开始初步尝试微服务架构。 能看出制造业向“智造”转型的影响,今天的制造业结合了物联网、传感器、云计算、大数据等技术,人工智能技术正在工业、汽车驾驶等领域应用。大量新兴业务场景出现,服务变得复杂,产业的弯道超车带来了明显的微服务需求。
 

image007.jpg



其次,需求明显的为金融行业,包括银行、保险、证券等。尤其是一些国有银行、股份制银行以及城商行等大行都走在架构改造的前列。在自己的创新业务,如手机银行、微信银行、互联网理财等业务上试水微服务架构。在核心业务系统方面,则相当谨慎。一方面是由于监管和政策的原因,另一方面,银行开发体系庞大,IT架构变革将是一件非常复杂的事情。

5、微服务推进障碍

微服务不是完美架构,会带来系统的各种复杂度,以及运维要求更高等诸多难点 微服务并不是一项横空出世的技术,事实上MicroService的概念已经诞生多年。除了组件和技术不成熟,企业业务模式不急迫的因素外,微服务本身也有自己的劣势。

image008.jpg



本次调研,有近一半的企业会谈到对微服务的顾虑。比如部署以后的复杂度,后期运维管理的不友好等等。对于团队来说,搭建微服务架构上手难,运维效率低,运维成本高。另外,还可能带来团队之间沟通上的冲突,微服务需要与DevOps同步推进。微服务被分割成一个个独立的业务模块后,服务间通信接口设计非常重要。如何科学地将系统部署到服务器上,保证各个服务高效运行,更是难点。

微服务推进过程中有许多障碍。对微服务自身复杂度的担忧、缺少具备相关经验的专家、难以招募专业人才和使用相关工具是三个最普遍的障碍。其中对微服务复杂度的顾虑,排名前三的是运维要求和成本高,分布式架构的网络延迟、容错等挑战,以及较强的部署依赖性。

三、Docker与微服务

在接受调研的企业中,2017年在生产环境中采用Docker的比例为9%,测试环境使用达22%。而且规模越大的企业,尤其是服务器规模在500台以上的,是Docker容器的主要采用者。另外,正在考虑评估中的占到被调研企业的一半以上。企业的关注度急剧升高,Docker使用正在快速普及。

image009.jpg

 

容器和微服务相辅相成,两大技术成熟的时间点非常契合。容器技术的成熟为微服务提供了得天独厚的客观条件。轻量化的容器是微服务的最佳运行环境,微服务应用只有在容器环境下才能保障运维效率的提升。同时,微服务应用架构对外在组件的管理会变得困难,需要用容器平台去管理中间件,才能发挥出更大价值。

四、微服务化是一个体系,从架构、工具到团队协同

1、企业微服务架构改造需要包括周边配套工具链在内的一整套微服务体系

采用微服务架构改造应用系统,不仅仅是选择开发框架本身,还要建设一套完整的体系架构。既要实现应用模块之间的解耦,还要实现统一管理。

微服务化体系,包括开发框架、以及周边配套工具链和组件,比如服务注册、服务发现、API网关、负载均衡、服务治理、配置中心、安全管理、与容器的结合、监控管理等等。一整套的体系建设是微服务真正的难点所在。

落地过程中,受访企业关注的功能包括,API网关(33%)、服务治理(27%)、配置中心(21%)、分布式任务调度(17%)、应用监控与报警(11%)、高并发(7%)等。这些组件可以根据自身的业务特性选择使用。


image010.jpg


2、微服务落地方法论:咨询+产品工具+实施

在IT建设中,企业都希望将开发人员的精力放在自身业务系统的开发上,而工具的整合和使用则主要借助外部供应商的力量来做。软件外包商都有自己的发展历程,迅速改变技术架构不太现实。

另外,传统企业都有大量原有IT系统,掉头和转向不可能丢掉历史包袱,全部推翻重新建设。因此,企业一方面有架构之痛,另一方面不得不总是在业务系统快速上线和新架构选择之间平衡。

对于企业来说,最实际的微服务落地路径是,首先纳入微服务咨询,引入外部行业技术专家角色,站在企业架构的总体高度,帮助企业进行微服务体系规划,落地roadmap,然后借助一些产品和工具进行落地实施。

在本次调研中,有的企业鉴于微服务的优势和业务快速变化的需要,会在新项目建设时直接选择微服务架构进行开发,落地方法也不例外。

3、企业践行微服务的三种类型

目前微服务落地的企业可以分为:温柔型的变革者、业务倒逼型的强硬者、观望型的探索者。

具体来说,温柔的变革者从边缘非核心业务探索尝试新兴技术。渐进式实施、创新灵活多变业务是这类型客户微服务切入的关键词。也是大部分传统企业在切入微服务时,选择的路径。

本次参与调研的企业多是如此,在切入微服务时,选择了诸如测试流程、API网关、开发平台升级、测试环境快速部署等非核心业务进行技术验证。


image011.jpg


业务倒逼型是那些企业核心业务系统在日常支撑中承受着巨大压力,必须进行架构改造,否则业务运转举步维艰。观望型的探索者,是那些出于业务考量,要看到行业标杆案例,明确收益和价值,以及技术风险和可靠性充分把握的情况下,才会投入资源开始改造。

4.微服务落地需要从上到下推动和密切团队协同

微服务应用的构建依赖组织结构的变化,它按照业务,而不是技术来划分组织,在推进过程中会受到从上到下的压力,因此必须有决策层的支持和推动。同时,需要团队更好的协同,小团队作战,打破团队间的高墙,减少沟通成本。上了微服务的受访企业对搭建一支敏捷团队都感受很迫切。

五、Service Mesh下一代微服务抢滩登陆

预计两年内服务网格技术将呈现爆发之势

本次的受访者中,有42%表示听说过 ServiceMesh 这一新兴技术理念,但只有6%的受访者对该技术有过一些研究。

image012.jpg



微服务带来的复杂度让企业头疼,尤其是服务间通信,如何保证服务间通信的端到端性能和可靠性,催生了下一代微服务Service mesh。2017年,ServiceMesh 经过技术拥趸、技术社区和媒体的反复布道,迅速被业界了解。

Service Mesh 是服务间通信层,可以提供安全、快速、可靠的服务间通讯。在过去的一年中,Service Mesh 已经成为微服务技术栈里的一个关键组件,被誉为“下一代微服务”。

Conduit、Istio 等Service Mesh技术在市场上已形成激烈的竞争,国内外企业开始纷纷站队。国外,一些有高负载业务流量的公司都在他们的生产应用里加入了Service Mesh。国内前沿技术公司开始围绕SpringCloud等开发体系,为客户提供成熟的解决方案和工具产品。同时,探索基于 ServiceMesh 的新方案,积极拥抱Istio/Conduit。

当然对于传统企业来说,技术的先进性是为了保障业务需求的快速变化和发展,而不是一味追求新兴。受访企业表示,一方面会主动关注新技术的最新动向,另一方面在考虑落地时,也要关注新技术的可靠性和有例可循,有无业界最佳实践背书。

六、结论

微服务的核心使命是简化开发,提高IT系统对业务的支撑能力。通过本次调研,我们可以得出如下一些结论:

1.传统行业新兴业务对IT效率的变革需求,业务模式创新重塑要求IT快速响应,是今天微服务炙手可热的主要驱动因素。从目前微服务落地的状态预估有两年左右的培育和成长期。


image013.jpg


评估一家企业是否需要上微服务,主要考察这五大关键要素:数据量和业务复杂度,团队规模,应对业务流量变化,是否需要足够的容错容灾,以及功能重复度和差错成本。

2. 实施微服务的理想技术条件包括:进程隔离、数据库表隔离,以及通过公开接口访问。

image014.jpg



3. 微服务架构在企业的使用可以分为四个层次:初级使用者、轻度使用者、中度使用者,以及重度使用者。

image015.jpg



以技术见长的大型互联网公司首先引领了微服务的风潮,国内制造、金融等大型龙头企业中也有佼佼者开始规划微服务体系,且具备较强的研发实力。大部分企业还处在初步尝试,不成体系,寻找技术和专家力量探讨解决方案的阶段。

4.微服务和容器共生:容器和微服务相辅相成,天生一对。Docker的成熟,让微服务推广和落地更加可靠、方便。随着Docker和微服务架构组件等相关技术的逐步成熟,微服务架构将逐步落地传统企业。 


image016.jpg


5.微服务落地方法论:微服务主要用来解决系统的复杂性问题,企业客户对于如何实施微服务并不清晰,同时有诸多顾虑。受企业客户青睐的落地方法是:微服务咨询+产品工具+实施。 

image017.jpg



6.微服务落地策略:微服务正成为许多企业构建应用时的首选。微服务并不缺乏受众,有的企业将微服务用于新应用开发,有的关注将单体应用迁移到微服务架构。微服务改造循序渐进,快速演化只会适得其反。另外,落地过程中注意开发和运维部门的协同,进行组织内管理创新。 

image018.jpg



关于调研对象

本次调研我们总计收到了来自182家企业受访者的调研问卷,并现场调研部分受访企业。覆盖制造/航空、金融、互联网、地产、交通物流和零售等行业,受访者包括CIO、CTO等IT高管,及开发、基础架构部门IT人员。

参考资料: 
1.The State of Microservices Survey 2017 – Eight Trends You Need to Know 
https://dzone.com/articles/the ... trend 
2、Microservices: Breaking Down the Monolith 
https://dzone.com/guides/micro ... olith 
3.微服务企业级落地将会带来哪些转变? 
http://mp.weixin.qq.com/s/3LkU4OwpgSPdFFY5__dheQ 
4.深度剖析微服务架构的九大特征 
http://developer.51cto.com/art/201608/516401.htm

那些没说出口的研发之痛,做与不做微服务的几大理由

杨y 发表了文章 • 0 个评论 • 149 次浏览 • 2018-01-09 17:50 • 来自相关话题

原文链接
 如果在诸多热门云计算技术中,诸如容器、微服务、DevOps等,找出一个最火的方向,那么非微服务莫属。在小数推荐的这篇文章里,做与不做微服务好像理由都很充分。另外,诞生几十年的康威定律,在组织结构调整和变革方面,依然神采奕奕。
创建一种新的软件项目架构,来封装离散服务,对于全新的项目来说,这是非常简单的。但是,对于大多数软件开发者来说,谁又有大把的奢侈时间一直用在全新项目上呢?

大多数软件开发人员职责更多是维护或增加现有软件系统的功能。但是,如果问开发人员究竟是愿意构建全新的项目,还是维护一个现有的系统,那么支持新项目的呼声肯定会成为压倒性的声音。事实上,希望与新技术或新项目合作也是开发人员离职的原因之一。为什么呢?



1识别问题容易,但修复很难

维护现有系统时,很容易识别架构的问题。为什么?因为基于良好的架构,系统很容易调整。


当需要去调整一个没有设计封装波动的已有系统时,架构的弱点就不言自明。即使是最小的表层变化也会给整个系统的其他部分带来复杂的涟漪:新的依赖看似要无止境地延续下去,通过臃肿的方法签名获得更多的参数,自动化测试的规模和复杂性爆炸,同时降低了实际效用。


这些问题是不是听起来很熟悉?你企业的架构是这样的吗?


如果答案是肯定的,那么你有一个单体架构。单体架构是大多数软件开发者遇到的最常见架构。
 
这个单体架构来自那些根本没有设计封装波动的系统,但是随着业务需求和时间的推移,变得越来越复杂。


那么用单体架构做什么呢?
每个人在单体架构中工作时都会感到痛苦,开发和业务人员也是如此。开发者讨厌臃肿的单体架构,因为开发的难度会随着新开发动作的增加而增加。一旦单体架构达到临界值,如何改变会成为一个真正可怕的命题。这会导致生产力和团队士气下降,业务受到影响。企业需要快速行动,单体架构却会随着时间的推移而变得越来越慢。


许多开发人员都希望把已有的架构丢掉,重新开始,但是这种想法无法和业务一起成长。“最好的软件是目前就让企业赚钱的软件,无论设想中的新版本多么伟大!”
所以新的计划不能完全抛弃旧有的单体架构,业务要继续,但不会再增加单体架构的复杂度。  


微服务?

微服务是一个流行的词汇,它模糊地表达了一个面向服务的架构,其中包含许多小的离散服务。

从表面上看,微服务似乎是单体架构的对立面(每个人都讨厌单体架构),许多微服务通过提出新的特性请求,并以独立服务的形式出现。这里的问题是:当单体架构封装所有系统的波动性,解耦的独立服务并不能使企业免于任何波动。


以下是用微服务实现单个功能架构,它大概像这个样子:
单体应用变得小了一点,新功能清晰地从系统的其余部分解耦。这很好吗?
当下一个功能请求进入时会发生什么?






有两个功能,我们已经看到一个问题。第二个功能建立在第一个功能之上,所以不能完全隔离。




如果随着功能请求的进入,简单地创建新的微服务,而不是封装整个波动区域:

有改善吗?来看看原始单体应用旁边的微服务:

如果仔细观察,会发现,所有服务依赖线模糊在一起,这只是发明了一个更复杂的单体架构。

小小的改变在整个系统中仍然会带来复杂的涟漪。整个系统的行为改变将涉及到改变多个微服务。所有相同的问题再次出现,甚至可能更糟糕,这加剧了依赖关系难以追踪的事实,而且,精心策划的多服务部署比庞大的单体应用更加可怕。


什么地方出了错?

问题源于微服务本身不是架构。微服务就是一个简单的词,描述了作为独立服务运行的系统,而不是一个单体应用。软件架构的实际实践包括仔细规划,在哪里划分离散服务之间的界限,从而包含波动区域。当简单地拿出一个单体应用,作为独立服务来实施时,就没有必要来考虑整个系统的封装波动。


把系统看作一个整体,才能谈架构

因此,如果单体应用,功能驱动的微服务太小,该怎么做应对?


要知道想去的方向

要像从头开始创建一样,为整个系统设计理想的架构。

企业不能一下子从一个单体架构直接进入微服务架构,但是如果第一次启动的时候,不清楚想达成的方向,那么永远也不会到达那里。
 
给所有希望拆分现有单体应用的软件开发者提供一些建议,但实际情况是这个路线图对于每个系统都是独一无二的。Tips如果只是设计新的功能而忽略已有的单体应用,则无法创建出色的架构;

如果不考虑整个系统,单体应用就不能有效分解;

微服务只是一个流行词。更小并不总是更好。精心拆分服务边界很重要;

2微服务与团队:康威定律

微服务架构是独特的,随着时间的推移仍然保持灵活性,在一个项目的组织架构中时时发生影响 。对于大多公司而言,这非常具有挑战性,因为它要求企业重新考虑组织模式。当准备开始微服务架构时,可以先问自己:“企业的组织能力是什么?“在早期,先决条件应该是预先准备会遇到的困难,并思考应对之策。

微服务与康威定律:企业需要与团队协同的架构

当涉及到组织团队和微服务,著名的康威定律经常被提到。这项定律,越来越被广泛地接受。

这一定律的缺陷在于,它更多是一种社会学规律,而不是纯粹的科学规律,事实上,它总是以实证、实例的方式,而不是纯粹的科学逻辑来论证。一般来说,社会学的结果很难证明,因为这些论证很大程度上基于假想中的思考和概念,只能通过更多的实例来加以验证。

“组织的系统设计…往往受限于组织架构的产品设计和通信的副本。”从这个规律,可以得出一些简单的结论:

如果想要特定的结构,需要一个与组织团队协同的架构。

如果经常改变架构,组织团队也需要经常修改。

这两个断言,对于康威定律的原则,有着深远的影响。首先是一个企业的适应能力,避免了野心家的倾向,对变革的抵制等等,也引发了机器取代人力的哲学思考。

基于以上结论,要上微服务架构的第一个问题是:“组织团队如何适应这种架构?” Netflix 和亚马逊的情况,当然是很正向的,但是否你的企业是否准备好了?其中重要的是,挖掘技巧和发现问题时的“刹车”措施来规避风险。

其中的技巧能迅速提升团队的能力。在创建一个功能时,负责功能实现的团队汇集了很多不同的技巧。当架构进入微服务模式时,将出现更多的协调性需求。


另一个窍门是开源技术的治理模式。开源项目由于其分散的结构,使它能够创建高度松耦合的软件,这是微服构的优点之一。它因此成为与其他团队的协作方式,并推动具有代码能力的小团队,在代码中实现变化。


但是,这个逻辑和组织变革在公司的接受度如何?这些技巧是否足够在全公司范围内协调、积累经验和知识?分散的组织构建松耦合的代码,但技术或功能性的知识和技能不可能极端的解耦。否则,这就像拆东墙补西墙,是在用拆掉的墙来构建松耦合的架构。

真正的僵局会出现在文化和管理风格上,这点在最近几年有了好转。

一个比较好的例子是Spotify的框架(虽然我们应该限制自己使用meta frameworks,原因不再赘述)。Spotify采用通过使用开源组件来架构功能和治理,使用这些工具在一定规模下实现了灵活性矩阵模型。矩阵式组织必须确保知晓不同人具备的知识或技能。

最近流行的新管理方法已初见影响,特别是在那些寻求实现微服务的团队组织中。

Holacracy管理模式:满足业务模式前提下,完成微服务最佳实践

上面谈到了企业文化、主体、和变革的阻力。第一种类型的管理,来源于 Holacracy 管理模式。

Holacracy分为自治和独立,并链接比自己更高的实体。这些圈子以闭环的形式,可以互相重叠,具有自组织而被上层管理的特殊性。每个圈子对于性质和组成的变化非常敏感。

可以想象,例如,底层圈子是微服务的开发队伍,而上一层是架构和产品负责人,最顶端是应用的客户业务线。这将让产品和架构负责人要能在满足业务需求的前提下,才能保证架构的最佳实践。

这种架构方式也是开发者、软件架构师的典型方式。所有可能来自不同或重叠的圈子组织。建立这种类型的组织是为了提高知识传输和构建架构的时间效率。

我们可能会认为,这种管理比较符合传统的层级组织。事实上,即使层次是扁平的,它仍然存在,可以限制其项目团队。总之,最好的方式就是简化人与人之间的链接。


  查看全部
原文链接
 如果在诸多热门云计算技术中,诸如容器、微服务、DevOps等,找出一个最火的方向,那么非微服务莫属。在小数推荐的这篇文章里,做与不做微服务好像理由都很充分。另外,诞生几十年的康威定律,在组织结构调整和变革方面,依然神采奕奕。
创建一种新的软件项目架构,来封装离散服务,对于全新的项目来说,这是非常简单的。但是,对于大多数软件开发者来说,谁又有大把的奢侈时间一直用在全新项目上呢?

大多数软件开发人员职责更多是维护或增加现有软件系统的功能。但是,如果问开发人员究竟是愿意构建全新的项目,还是维护一个现有的系统,那么支持新项目的呼声肯定会成为压倒性的声音。事实上,希望与新技术或新项目合作也是开发人员离职的原因之一。为什么呢?



1识别问题容易,但修复很难

维护现有系统时,很容易识别架构的问题。为什么?因为基于良好的架构,系统很容易调整。


当需要去调整一个没有设计封装波动的已有系统时,架构的弱点就不言自明。即使是最小的表层变化也会给整个系统的其他部分带来复杂的涟漪:新的依赖看似要无止境地延续下去,通过臃肿的方法签名获得更多的参数,自动化测试的规模和复杂性爆炸,同时降低了实际效用。


这些问题是不是听起来很熟悉?你企业的架构是这样的吗?


如果答案是肯定的,那么你有一个单体架构。单体架构是大多数软件开发者遇到的最常见架构。
 
这个单体架构来自那些根本没有设计封装波动的系统,但是随着业务需求和时间的推移,变得越来越复杂。


那么用单体架构做什么呢?
每个人在单体架构中工作时都会感到痛苦,开发和业务人员也是如此。开发者讨厌臃肿的单体架构,因为开发的难度会随着新开发动作的增加而增加。一旦单体架构达到临界值,如何改变会成为一个真正可怕的命题。这会导致生产力和团队士气下降,业务受到影响。企业需要快速行动,单体架构却会随着时间的推移而变得越来越慢。


许多开发人员都希望把已有的架构丢掉,重新开始,但是这种想法无法和业务一起成长。“最好的软件是目前就让企业赚钱的软件,无论设想中的新版本多么伟大!”
所以新的计划不能完全抛弃旧有的单体架构,业务要继续,但不会再增加单体架构的复杂度。  


微服务?

微服务是一个流行的词汇,它模糊地表达了一个面向服务的架构,其中包含许多小的离散服务。

从表面上看,微服务似乎是单体架构的对立面(每个人都讨厌单体架构),许多微服务通过提出新的特性请求,并以独立服务的形式出现。这里的问题是:当单体架构封装所有系统的波动性,解耦的独立服务并不能使企业免于任何波动。


以下是用微服务实现单个功能架构,它大概像这个样子:
单体应用变得小了一点,新功能清晰地从系统的其余部分解耦。这很好吗?
当下一个功能请求进入时会发生什么?






有两个功能,我们已经看到一个问题。第二个功能建立在第一个功能之上,所以不能完全隔离。




如果随着功能请求的进入,简单地创建新的微服务,而不是封装整个波动区域:

有改善吗?来看看原始单体应用旁边的微服务:

如果仔细观察,会发现,所有服务依赖线模糊在一起,这只是发明了一个更复杂的单体架构。

小小的改变在整个系统中仍然会带来复杂的涟漪。整个系统的行为改变将涉及到改变多个微服务。所有相同的问题再次出现,甚至可能更糟糕,这加剧了依赖关系难以追踪的事实,而且,精心策划的多服务部署比庞大的单体应用更加可怕。


什么地方出了错?

问题源于微服务本身不是架构。微服务就是一个简单的词,描述了作为独立服务运行的系统,而不是一个单体应用。软件架构的实际实践包括仔细规划,在哪里划分离散服务之间的界限,从而包含波动区域。当简单地拿出一个单体应用,作为独立服务来实施时,就没有必要来考虑整个系统的封装波动。


把系统看作一个整体,才能谈架构

因此,如果单体应用,功能驱动的微服务太小,该怎么做应对?


要知道想去的方向

要像从头开始创建一样,为整个系统设计理想的架构。

企业不能一下子从一个单体架构直接进入微服务架构,但是如果第一次启动的时候,不清楚想达成的方向,那么永远也不会到达那里。
 
给所有希望拆分现有单体应用的软件开发者提供一些建议,但实际情况是这个路线图对于每个系统都是独一无二的。Tips如果只是设计新的功能而忽略已有的单体应用,则无法创建出色的架构;

如果不考虑整个系统,单体应用就不能有效分解;

微服务只是一个流行词。更小并不总是更好。精心拆分服务边界很重要;

2微服务与团队:康威定律

微服务架构是独特的,随着时间的推移仍然保持灵活性,在一个项目的组织架构中时时发生影响 。对于大多公司而言,这非常具有挑战性,因为它要求企业重新考虑组织模式。当准备开始微服务架构时,可以先问自己:“企业的组织能力是什么?“在早期,先决条件应该是预先准备会遇到的困难,并思考应对之策。

微服务与康威定律:企业需要与团队协同的架构

当涉及到组织团队和微服务,著名的康威定律经常被提到。这项定律,越来越被广泛地接受。

这一定律的缺陷在于,它更多是一种社会学规律,而不是纯粹的科学规律,事实上,它总是以实证、实例的方式,而不是纯粹的科学逻辑来论证。一般来说,社会学的结果很难证明,因为这些论证很大程度上基于假想中的思考和概念,只能通过更多的实例来加以验证。

“组织的系统设计…往往受限于组织架构的产品设计和通信的副本。”从这个规律,可以得出一些简单的结论:

如果想要特定的结构,需要一个与组织团队协同的架构。

如果经常改变架构,组织团队也需要经常修改。

这两个断言,对于康威定律的原则,有着深远的影响。首先是一个企业的适应能力,避免了野心家的倾向,对变革的抵制等等,也引发了机器取代人力的哲学思考。

基于以上结论,要上微服务架构的第一个问题是:“组织团队如何适应这种架构?” Netflix 和亚马逊的情况,当然是很正向的,但是否你的企业是否准备好了?其中重要的是,挖掘技巧和发现问题时的“刹车”措施来规避风险。

其中的技巧能迅速提升团队的能力。在创建一个功能时,负责功能实现的团队汇集了很多不同的技巧。当架构进入微服务模式时,将出现更多的协调性需求。


另一个窍门是开源技术的治理模式。开源项目由于其分散的结构,使它能够创建高度松耦合的软件,这是微服构的优点之一。它因此成为与其他团队的协作方式,并推动具有代码能力的小团队,在代码中实现变化。


但是,这个逻辑和组织变革在公司的接受度如何?这些技巧是否足够在全公司范围内协调、积累经验和知识?分散的组织构建松耦合的代码,但技术或功能性的知识和技能不可能极端的解耦。否则,这就像拆东墙补西墙,是在用拆掉的墙来构建松耦合的架构。

真正的僵局会出现在文化和管理风格上,这点在最近几年有了好转。

一个比较好的例子是Spotify的框架(虽然我们应该限制自己使用meta frameworks,原因不再赘述)。Spotify采用通过使用开源组件来架构功能和治理,使用这些工具在一定规模下实现了灵活性矩阵模型。矩阵式组织必须确保知晓不同人具备的知识或技能。

最近流行的新管理方法已初见影响,特别是在那些寻求实现微服务的团队组织中。

Holacracy管理模式:满足业务模式前提下,完成微服务最佳实践

上面谈到了企业文化、主体、和变革的阻力。第一种类型的管理,来源于 Holacracy 管理模式。

Holacracy分为自治和独立,并链接比自己更高的实体。这些圈子以闭环的形式,可以互相重叠,具有自组织而被上层管理的特殊性。每个圈子对于性质和组成的变化非常敏感。

可以想象,例如,底层圈子是微服务的开发队伍,而上一层是架构和产品负责人,最顶端是应用的客户业务线。这将让产品和架构负责人要能在满足业务需求的前提下,才能保证架构的最佳实践。

这种架构方式也是开发者、软件架构师的典型方式。所有可能来自不同或重叠的圈子组织。建立这种类型的组织是为了提高知识传输和构建架构的时间效率。

我们可能会认为,这种管理比较符合传统的层级组织。事实上,即使层次是扁平的,它仍然存在,可以限制其项目团队。总之,最好的方式就是简化人与人之间的链接。


 

容器之后的下一个明星,关于无服务器(Serverless)架构你要搞懂的8件事

杨y 发表了文章 • 0 个评论 • 148 次浏览 • 2018-01-04 06:52 • 来自相关话题

无服务器计算,虽然神秘,但一定会成为IT行业最有力的工具之一。这种可能改变游戏规则的技术虽然不是全新的,但就像之前的容器技术一样,有一些神化和误解。
1
1什么是无服务器(Serverless)计算?
无服务器计算允许企业构建、运行应用和服务而不用去考虑服务器。无服务器应用不需要管理任何服务器,而且任何类型的应用或后端服务都可以构建为无服务器应用。运行应用以及应用高可用所需要的一切,都由云服务商来提供。
无服务器应用程序有四大优势:
1)不需要管理服务– 不需要提供或维护任何的服务器,不需要安装任何的软件或运行时。
2)弹性扩缩–应用程序扩缩能自动完成或是通过调整其资源使用量来调整容量,而不是通过增减服务器的数量。
3)高可用-无服务器应用程序内置高可用和容错。无需考虑高可用,运行应用的服务默认提供高可用。
4)没有闲置损耗-不需要对计算和存储之类的服务预留容量。如果代码没有运行,就不会收费。
构建无服务器应用程序意味着开发者可以专注在产品代码上,而无须管理和操作云端或本地的服务器或运行时。
2无服务器(Serverless)计算如何工作?
与使用虚拟机或一些底层的技术来部署和管理应用程序相比,无服务器计算提供了一种更高级别的抽象。因为它们有不同的抽象和“触发器”的集合。
拿计算来讲,这种抽象有一个特定函数和抽象的触发器,它通常是一个事件。以数据库为例,这种抽象也许是一个表,而触发器相当于表的查询或搜索,或者通过在表中做一些事情而生成的事件。
比如一款手机游戏,允许用户在不同的平台上为全球顶级玩家使用高分数表。当请求此信息时,请求从应用程序到API接口。API接口或许会触发 aws 的Lambda函数,或者无服务器函数,这些函数再从数据库表中获取到数据流,返回包含前五名分数的一定格式的数据。
一旦构建完成,应用程序的功能就可以在基于移动和基于 web 的游戏版本中重用。
这跟设置服务器不同,不是必须要有Amazon EC2实例或服务器,然后等待请求。环境由事件触发,而响应事件所需的逻辑只在响应时执行。这意味着,运行函数的资源只有在函数运行时被创建,产生一种非常高效的方法来构建应用程序。
3适用于哪些场景?
无服务器计算适合于任何事件驱动的各种不同的用例。这包括物联网,移动应用,基于网络的应用程序和聊天机器人。事件是由人的动作(比如按下按钮),传感器或者系统中的数据流产生。
这方面的一个例子是,Thomson Reuters(人名)使用AWS Lambda来加载和处理数据流,而无需提供或管理任何服务器。Thomson Reuters建立了一个解决方案,使其能够捕捉、分析和可视化其产品所生成的分析数据,提供帮助产品团队不断改进用户体验的见解。
AWS Lambda只在通过与其他AWS服务、Kinesis和AmazonS3集成的新数据条目触发时运行代码。
在事件驱动下,当代码运行时,公司只收取计算处理的费用,这是非常节约成本的。
4不适用哪些场景?
对于已经构建的遗留应用程序来说,这不一定是一个完全的解决方案。如果是一个单体应用或者应用需要运行在操作系统级别,这样的应用就不适合在无服务器平台上运行。这并不意味着这样的应用没法实现无服务器架构,它只是意味着需要重新构建应用程序。
一个很好的例子是web应用程序,可以在应用程序服务器(如Tomcat)中将其作为一个大型的单体job运行。如果要将应用程序分解为复合函数集,则可以使用无服务器模型实现所有的新功能。随着时间的推移,旧版本应用程序的使用级别越来越小,这些新的无服务器组件的使用率随着使用量的增加而增加。对于这样的客户,都有一个过渡模型,客户可以遵循这种过渡模式,将传统的基于机器的应用程序架构迁移到基于功能的架构。
5无服务器(Serverless)计算贵吗?
并不贵。只需要支付企业所使用的部分,没有任何与无服务器计算相关的成本。特别对于小的用例,应用程序使用随时间变化大的企业是非常划算的。
对于希望管理工作负载和操作的客户来说,它也非常划算,因为它可以使客户避免成本,例如容量规划或部署工具。许多AWS的客户,现在正在尝试用服务器来提高敏捷度,同时也节省了成本。健康零食公司Graze有许多使用for AWS的方法,包括将分析数据实时上传至亚马逊RedShift、管理备份和检查GitHub拉请求,希望在未来几个月内将其使用量增加两到三倍。
6无服务器(Serverless)的行业炒作
无服务器计算得到了开发人员的积极响应。在以资源有效的方式交付应用程序时,它提供了更多的选项和可能性。
很多大型的企业,比如Netflix,已经在探索无服务器计算,希望解放开发人员的时间。Netflix使用AWS Lambda来构建基于规则的自我管理基础设施,并替换低效的流程,减少错误的速率,为开发人员节省宝贵的时间。
以前,云开发者必须使用那些耗费大量人力和时间的机器。无服务器技术允许开发人员在几分钟内运行测试和产品。开发人员直接控制部署时间以及如何部署,通过建模框架控制应用架构。还允许发布自己的产品并亲自体验。
2
容器和无服务器(Serverless)
无服务器计算和容器之间正在酝酿一场战斗——当尘埃落定时,谁会倒下?会是容器吗?
如前所述,无服务器具备一些明显的优势。比如节省成本,提高IT支出的效率,减少资源和维护需求,允许开发人员和IT人员专注于高价值的任务等等。这也是为什么人们会对这项技术充满热情的原因。但是,通往无服务器的路径并不轻松。
SetfiveConsulting 的合伙人 Ashish Datta 说,将基于容器的架构迁移到无服务器通常需要重新架构系统的重要部分。
“与从虚拟机到容器的转换相比,从容器到无服务器的转换更有戏剧性,因为容器和无服务器之间的计算环境发生了根本性的变化。”
相反,从虚拟机到容器的迁移更为直接,因为这实际上只是部署哲学的变化。
Stackery CEO Nate Taggart说,最大的障碍是企业无法轻易地迁移到无服务器架构上。
“(无服务器应用程序)必须是为无服务器基础设施设计的。这对于新的开发来说可能是相当经济的,但是迁移遗留应用程序将是很繁重的,在某些情况下甚至是不可能的。
今天的无服务器产品有资源的限制,Taggert解释道,包括内存、计算和时间限制;有限的语言支持;以及在请求之间管理状态的特殊考虑。所有这些都必须“从一开始就融入到应用程序设计中”,Taggert说。
PubNub的产品营销总监James Riseman说,迁移到无服务器架构还需要对现有基础设施进行重大的反思。
“无服务器计算需要一个非常现代的、组件化的架构。系统和应用程序必须被分解成离散的逻辑函数,而要保证这样的质量企业会失去控制。” JamesRiseman 表示。
无服务器的另一个问题是定价。“公司是按照每笔交易或每秒钟计费,而不是按照传统的基础设施条款,”Siseman说。“这使得定价更加难以预测。”
除了地址迁移需求之外,转向无服务器计算还会导致思维模式的改变。
“最大的障碍之一是,需要考虑在离散的单元中计算资源,而不是始终占用进行计算。”这与对内存使用量和运行时等框架的限制相吻合,比如Amazon Lambda这样的框架。“Atta说道。
1对手还是盟友?
撇开正反两方面的因素不说,在面对面的交锋中,容器和无服务器是相互排斥的解决方案。但是每个人都说这样想是错误的。
SwymSystems CEO兼首席顾问Todd Millecam 表示,这是一种苹果和橘子的比较。“两者都有使用,如果观察大多数无服务器技术的运行方式,它们只是在后台运行容器。”
无服务器和容器是互相补充而并非重叠的角色。Taggart说,虽然两者都可以用于计算任务,但每个任务都有其优缺点。无服务器是一种理想的、可预测的、具有小型资源需求和短期事务的工作负载。
容器对于长时运行的流程和可预测的工作负载具有优势。容器在应用程序设计方面也提供了更多的灵活性,但需要对底层基础架构进行更多的管理。
 “作为一个无服务器操作控制台产品,我们有一个几乎完全没有服务器的后端,”Taggart补充说,但是仍然使用容器来处理某些工作负载,在这些工作负载中,它们是更好的工作工具
2Serverless是未来吗?
看来,关于容器式微的谣言被夸大了。
Datta说,不同的架构和应用程序总是需要不同程度的抽象,同样,不同的团队也会对做出不同的权衡。
正如容器没有取代虚拟机,虚拟机也没有取代裸金属的服务器。抽象不会成为“更接近金属”的解决方案的生死存亡的威胁。
无服务器,应该被看作是技术的进化。大多数观察者警告说,无服务器仍然不成熟,还没有建立架构模型和健壮的开发工具。这意味着将企业应用程序的命运与特定的云供应商绑定,将带来自身的风险。
因此,尽管它有巨大的潜力,但可能需要数年才能在企业中获得广泛的应用。
同时,无服务器将会对创业公司产生重大影响。
 “无服务器计算提供了一种托管代码的方法,并以很低廉的成本在web上可用。在拥有活跃的用户基础之前,无服务器是构建web应用程序的一种划算的方式。”Millecam说道。
不过,数字机构POP CTO Jake Bennett 表示,随着无服务计算技术的成熟,架构师会发现无服务器将越来越难以抗拒。“无服务器计算解决了太多被忽视的问题。将对可伸缩性问题的关注转移给第三方供应商,是每个开发人员的梦想,让别人关心服务器维护是IT运维人员的一种幻想。”
 
原文链接:
1、Everything you need to know about Serverless Computing
https://www.tuicool.com/articles/yMZVfev
2、Serverless and containers: Is a throw down under way?
https://www.tuicool.com/articles/BvUziyY 查看全部

无服务器计算,虽然神秘,但一定会成为IT行业最有力的工具之一。这种可能改变游戏规则的技术虽然不是全新的,但就像之前的容器技术一样,有一些神化和误解。
1
1什么是无服务器(Serverless)计算?
无服务器计算允许企业构建、运行应用和服务而不用去考虑服务器。无服务器应用不需要管理任何服务器,而且任何类型的应用或后端服务都可以构建为无服务器应用。运行应用以及应用高可用所需要的一切,都由云服务商来提供。
无服务器应用程序有四大优势:
1)不需要管理服务– 不需要提供或维护任何的服务器,不需要安装任何的软件或运行时。
2)弹性扩缩–应用程序扩缩能自动完成或是通过调整其资源使用量来调整容量,而不是通过增减服务器的数量。
3)高可用-无服务器应用程序内置高可用和容错。无需考虑高可用,运行应用的服务默认提供高可用。
4)没有闲置损耗-不需要对计算和存储之类的服务预留容量。如果代码没有运行,就不会收费。
构建无服务器应用程序意味着开发者可以专注在产品代码上,而无须管理和操作云端或本地的服务器或运行时。
2无服务器(Serverless)计算如何工作?
与使用虚拟机或一些底层的技术来部署和管理应用程序相比,无服务器计算提供了一种更高级别的抽象。因为它们有不同的抽象和“触发器”的集合。
拿计算来讲,这种抽象有一个特定函数和抽象的触发器,它通常是一个事件。以数据库为例,这种抽象也许是一个表,而触发器相当于表的查询或搜索,或者通过在表中做一些事情而生成的事件。
比如一款手机游戏,允许用户在不同的平台上为全球顶级玩家使用高分数表。当请求此信息时,请求从应用程序到API接口。API接口或许会触发 aws 的Lambda函数,或者无服务器函数,这些函数再从数据库表中获取到数据流,返回包含前五名分数的一定格式的数据。
一旦构建完成,应用程序的功能就可以在基于移动和基于 web 的游戏版本中重用。
这跟设置服务器不同,不是必须要有Amazon EC2实例或服务器,然后等待请求。环境由事件触发,而响应事件所需的逻辑只在响应时执行。这意味着,运行函数的资源只有在函数运行时被创建,产生一种非常高效的方法来构建应用程序。
3适用于哪些场景?
无服务器计算适合于任何事件驱动的各种不同的用例。这包括物联网,移动应用,基于网络的应用程序和聊天机器人。事件是由人的动作(比如按下按钮),传感器或者系统中的数据流产生。
这方面的一个例子是,Thomson Reuters(人名)使用AWS Lambda来加载和处理数据流,而无需提供或管理任何服务器。Thomson Reuters建立了一个解决方案,使其能够捕捉、分析和可视化其产品所生成的分析数据,提供帮助产品团队不断改进用户体验的见解。
AWS Lambda只在通过与其他AWS服务、Kinesis和AmazonS3集成的新数据条目触发时运行代码。
在事件驱动下,当代码运行时,公司只收取计算处理的费用,这是非常节约成本的。
4不适用哪些场景?
对于已经构建的遗留应用程序来说,这不一定是一个完全的解决方案。如果是一个单体应用或者应用需要运行在操作系统级别,这样的应用就不适合在无服务器平台上运行。这并不意味着这样的应用没法实现无服务器架构,它只是意味着需要重新构建应用程序。
一个很好的例子是web应用程序,可以在应用程序服务器(如Tomcat)中将其作为一个大型的单体job运行。如果要将应用程序分解为复合函数集,则可以使用无服务器模型实现所有的新功能。随着时间的推移,旧版本应用程序的使用级别越来越小,这些新的无服务器组件的使用率随着使用量的增加而增加。对于这样的客户,都有一个过渡模型,客户可以遵循这种过渡模式,将传统的基于机器的应用程序架构迁移到基于功能的架构。
5无服务器(Serverless)计算贵吗?
并不贵。只需要支付企业所使用的部分,没有任何与无服务器计算相关的成本。特别对于小的用例,应用程序使用随时间变化大的企业是非常划算的。
对于希望管理工作负载和操作的客户来说,它也非常划算,因为它可以使客户避免成本,例如容量规划或部署工具。许多AWS的客户,现在正在尝试用服务器来提高敏捷度,同时也节省了成本。健康零食公司Graze有许多使用for AWS的方法,包括将分析数据实时上传至亚马逊RedShift、管理备份和检查GitHub拉请求,希望在未来几个月内将其使用量增加两到三倍。
6无服务器(Serverless)的行业炒作
无服务器计算得到了开发人员的积极响应。在以资源有效的方式交付应用程序时,它提供了更多的选项和可能性。
很多大型的企业,比如Netflix,已经在探索无服务器计算,希望解放开发人员的时间。Netflix使用AWS Lambda来构建基于规则的自我管理基础设施,并替换低效的流程,减少错误的速率,为开发人员节省宝贵的时间。
以前,云开发者必须使用那些耗费大量人力和时间的机器。无服务器技术允许开发人员在几分钟内运行测试和产品。开发人员直接控制部署时间以及如何部署,通过建模框架控制应用架构。还允许发布自己的产品并亲自体验。
2
容器和无服务器(Serverless)
无服务器计算和容器之间正在酝酿一场战斗——当尘埃落定时,谁会倒下?会是容器吗?
如前所述,无服务器具备一些明显的优势。比如节省成本,提高IT支出的效率,减少资源和维护需求,允许开发人员和IT人员专注于高价值的任务等等。这也是为什么人们会对这项技术充满热情的原因。但是,通往无服务器的路径并不轻松。
SetfiveConsulting 的合伙人 Ashish Datta 说,将基于容器的架构迁移到无服务器通常需要重新架构系统的重要部分。
“与从虚拟机到容器的转换相比,从容器到无服务器的转换更有戏剧性,因为容器和无服务器之间的计算环境发生了根本性的变化。”
相反,从虚拟机到容器的迁移更为直接,因为这实际上只是部署哲学的变化。
Stackery CEO Nate Taggart说,最大的障碍是企业无法轻易地迁移到无服务器架构上。
“(无服务器应用程序)必须是为无服务器基础设施设计的。这对于新的开发来说可能是相当经济的,但是迁移遗留应用程序将是很繁重的,在某些情况下甚至是不可能的。
今天的无服务器产品有资源的限制,Taggert解释道,包括内存、计算和时间限制;有限的语言支持;以及在请求之间管理状态的特殊考虑。所有这些都必须“从一开始就融入到应用程序设计中”,Taggert说。
PubNub的产品营销总监James Riseman说,迁移到无服务器架构还需要对现有基础设施进行重大的反思。
“无服务器计算需要一个非常现代的、组件化的架构。系统和应用程序必须被分解成离散的逻辑函数,而要保证这样的质量企业会失去控制。” JamesRiseman 表示。
无服务器的另一个问题是定价。“公司是按照每笔交易或每秒钟计费,而不是按照传统的基础设施条款,”Siseman说。“这使得定价更加难以预测。”
除了地址迁移需求之外,转向无服务器计算还会导致思维模式的改变。
“最大的障碍之一是,需要考虑在离散的单元中计算资源,而不是始终占用进行计算。”这与对内存使用量和运行时等框架的限制相吻合,比如Amazon Lambda这样的框架。“Atta说道。
1对手还是盟友?
撇开正反两方面的因素不说,在面对面的交锋中,容器和无服务器是相互排斥的解决方案。但是每个人都说这样想是错误的。
SwymSystems CEO兼首席顾问Todd Millecam 表示,这是一种苹果和橘子的比较。“两者都有使用,如果观察大多数无服务器技术的运行方式,它们只是在后台运行容器。”
无服务器和容器是互相补充而并非重叠的角色。Taggart说,虽然两者都可以用于计算任务,但每个任务都有其优缺点。无服务器是一种理想的、可预测的、具有小型资源需求和短期事务的工作负载。
容器对于长时运行的流程和可预测的工作负载具有优势。容器在应用程序设计方面也提供了更多的灵活性,但需要对底层基础架构进行更多的管理。
 “作为一个无服务器操作控制台产品,我们有一个几乎完全没有服务器的后端,”Taggart补充说,但是仍然使用容器来处理某些工作负载,在这些工作负载中,它们是更好的工作工具
2Serverless是未来吗?
看来,关于容器式微的谣言被夸大了。
Datta说,不同的架构和应用程序总是需要不同程度的抽象,同样,不同的团队也会对做出不同的权衡。
正如容器没有取代虚拟机,虚拟机也没有取代裸金属的服务器。抽象不会成为“更接近金属”的解决方案的生死存亡的威胁。
无服务器,应该被看作是技术的进化。大多数观察者警告说,无服务器仍然不成熟,还没有建立架构模型和健壮的开发工具。这意味着将企业应用程序的命运与特定的云供应商绑定,将带来自身的风险。
因此,尽管它有巨大的潜力,但可能需要数年才能在企业中获得广泛的应用。
同时,无服务器将会对创业公司产生重大影响。
 “无服务器计算提供了一种托管代码的方法,并以很低廉的成本在web上可用。在拥有活跃的用户基础之前,无服务器是构建web应用程序的一种划算的方式。”Millecam说道。
不过,数字机构POP CTO Jake Bennett 表示,随着无服务计算技术的成熟,架构师会发现无服务器将越来越难以抗拒。“无服务器计算解决了太多被忽视的问题。将对可伸缩性问题的关注转移给第三方供应商,是每个开发人员的梦想,让别人关心服务器维护是IT运维人员的一种幻想。”
 
原文链接:
1、Everything you need to know about Serverless Computing
https://www.tuicool.com/articles/yMZVfev
2、Serverless and containers: Is a throw down under way?
https://www.tuicool.com/articles/BvUziyY