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

杨y 发表了文章 • 0 个评论 • 49 次浏览 • 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 个评论 • 79 次浏览 • 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 个评论 • 68 次浏览 • 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 个评论 • 72 次浏览 • 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 个评论 • 78 次浏览 • 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

配置中心一团糟?Hawk微服务化改造切合企业系统需求

杨y 发表了文章 • 0 个评论 • 75 次浏览 • 2017-12-28 19:05 • 来自相关话题

本文内容来自12月21日 DockOne 微信群线上分享







       微服务近年来炙手可热,如果在后端服务领域诸多热门技术趋势中,比如容器、微服务、DevOps等,找出一个最火的方向,那么非微服务莫属。微服务架构通过有效拆分应用,解耦系统,提供更好的软件伸缩性和企业的敏捷性,实现敏捷开发和部署。





它不是一种横空出世的技术,事实上微服务microservice的概念已经存在多年,一度曾是软件开发的宠儿。近年来被越来越多的企业和开发人员所推崇,并在互联网企业当中大量落地。一些有代表性的传统行业通过实施微服务架构,提高业务灵活性,加速业务需求变化和响应。




       微服务化作为一个体系,包括开发框架、以及周边配套工具链,比如服务治理、配置中心、安全管理、与容器的结合、监控管理等等。往往,围绕微服务的管理体系是微服务搭建的难点所在。




接下我们就谈谈配置中心的架构与实战。





1
为什么需要配置管理中心


       首先,我们的观点是,每一个稍微有点规模的分布式系统,都应该有一个统一配置中心。


当今的系统,随着系统的复杂度增加,配置也日益增多,随着devops等概念的推广,人们对配置的期望值也越来越高:期望配置修改后实时地生效,期望支持灰度发布,发布回滚,历史追踪,环境隔离,集群配置,服务治理等等,这个时候分布式统一配置中心就变得尤为重要。


配置中心解决什么痛点:把业务开发者从复杂以及繁琐的配置中解脱出来,只需专注于业务代码本身,从而能够显著提升开发以及运维效率。同时将配置和发布包解藕也进一步提升发布的成功率,并为运维的细力度管控、应急处理等提供强有力的支持。


配置中心的使用场景:在服务构建阶段,配合构建流水线,为服务软件包或镜像提供配置。

在服务运维阶段,动态调整服务配置,满足运维的灵活性需求。

在服务开发阶段,提供 OpenAPI,为其他基础设施的配置外置化,中心化提供支持。


配置中心Hwk产品需求:  基于上述一些列的特点,我们构思了自己的配置中心的产品需求:

为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持,实现了对服务端和客户端中环境变量,配置文件,动态属性配置的抽象映射,并支持配置的灰度下发,历史版本控制等先进功能

配置接口完全兼容 Spring Cloud Config,后台管理功能则通过 open API的形式对外开放,满足企业多样化的定制需求

管理Springcloud的微服务框架的业务配置,服务治理配置以及kubernetes的configmap和secrets的配置,同时也能通过插件的方式对流行的第三方类库提供特别支持,比如与 sharding-jdbc 的深度集成


2数人云hawk的架构







       配置中心是一个强一致性的系统,配置数据不一致会一起严重的业务问题, Hawk 使用读写分离的方式处理配置数据,Hawk Portal使用mysql 存储配置数据,并把通过审核的配置数据同步给 HawkServer,Hawk Server 使用etcd 来存储并下发的配置数据。认证与授权认证与授权分为 Hawk Portal 和 Hawk Server 两个部分来看。


Hawk Portal在用户使用 Hawk Portal 管理微服务应用和基础设施的配置之前,首选需要使用用户名与密码登录。这是一个简单的 Form based login,目前展示不考虑与企业的认证与授权中心进行单点登录,但需要能够允许用户通过存储在企业 LDAP 中的用户名和密码登录。


Hawk Server对于微服务应用通过 Hawk Client 向 Hawk Server 发起远程调用的时候,无需认证与授权过程,仅做必要的 TLS 对客户端进行身份认证。

当用户通过 Restful API 访问配置服务时,需要对用户的身份进行认证,用户的认证在 API Gateway 上完成而不是配置服务本身。服务发现etcd 同时也为 hawk 提供服务注册于发现的能力,Hawk Portal 与 Hawk Client 都通过 etcd 提供的能力发现和调用 Admin Service与 Config Service。配置存储企业基础设施与微服务应用的配置数据,以及 Hawk 配置中心本身的配置信息首先在 mysql 中落盘,仅当配置数据被激活后,才会同步到 Hawk Server,然后由 Sync Service 落盘到 etcd

领域模型。


集群管理Hawk 可以同时管理多个配置集群,devops 用户可以把不同的集群映射为不同的执行环境,比如开发环境 DEV,功能测试环境 FAT,验收测试环境 UAT等等,使用一套配置中心同时支持多种环境,降低维护成本。


生产环境一般不会与上述环境部署在一起,此时用户可以把配置集群映射到不同的部门,在物理上隔离不同部门的配置数据。

配置集群也可以用于在物理上隔离不同资源的配置,比如区分基础设施(消息中心,调度中心,微服务中心,存储中心)和微服务应用。配置下发微服务应用可以通过Hawk 提供的客户端 SDK Hawk Client 获取配置,也可以通过 Spring Cloud Zuul 服务网管来使用 Config Service 提供的兼容 Spring Cloud Config 的 Restful 接口。

 Hawk 可以通过推送的方式把配置变更直接下发给 Hawk Client ,通过这种方式,配置可以实现实时更新。

Hawk Client 在获取配置信息的同时会连接到配置信息所在的 etcd 集群,并 watch etcd 中的配置配置数据。当 etcd 集群中的配置信息更新后,Hawk Client 将会收到通知。

Hawk Client 提供原生接口允许微服务应用注册监听器监听配置信息的变化服务治理配置中心的配置管理和动态配置下发能力,使得它可以承担服务治理中的 Control Plane 的职责,它可以把服务治理相关的配置下发给实际的执行模块,比如 dubbo,或者是 Spring Cloud 集成的 Netflix 治理工具库,比如 hystrix 以及 ribbon。




服务治理的主要功能包括:

1. 注册/发现:服务实例启动后,将会自动通过 Hawk Client 向配置中心注册,运维可以在配置中心门户查看服务的实例列表,并进行实例级别的服务治理。

2. 负载均衡:调用其他服务时,可以灵活指定其负载均衡策略,如 round robin, hash, consistent hash, weight based round robin 等等。

3. 路由:配置微服务的路由策略和路由规则,路由策略如本地优先,本地数据中心优先等等,路由规则如白名单,黑名单,流量引导,读写分离,前后端分离,灰度升级等等。

4. 限流:针对某个调用方限流对象进行 QPS 限流,分钟级或秒级,或针对所有微服务客户端进行限流。

5. 降级:针对某个降级对象,进行手动或者自动降级(容错),并制定降级策略,抛出异常或特定返回值。

6. 容错:针对某个微服务,设定调用超时与重试策略。

7. 熔断:针对某个微服务或者 RPC方法,设定熔断的触发条件,可以强制熔断,或者自动熔断,也可以取消熔断,运维可以指定熔断参数,比如异常,错误码,失败次数比率,时间窗口,以及窗口请求书等等。3
Hawk基于Spring Cloud的服务治理
系统目标       抽象与具体的服务框架隔离的治理的数据域模型,在系统中均用系统的域模型表示所有的服务治理参数信息,下发到客户端后,能转化成相对应的服务配制信息。


功能分类1. 为其他应用提供服务:注册;

2. 为调用其他应用提供服务:发现和负载均衡;

3. 应用保护自己:熔断并且包含容错,降级。数据流向场景1. 用户在potal上配制a应用要调用的服务b和c,以及a应用的基于Hystrix的熔断配制信息,这些熔断配制可以保存客户端需要的熔断配制信息;

2. a应用启动,hawk client客户端启动;

3. hawk client到server拉取a应用的配制,a应用注册到hawk server;

4. a应用根据配制中的上游服务名b和c,发现提供b和c服务的实例;

5. 根据配制中的负载均衡的算法给每个上游业务配制负载均衡器;

6. 根据配制的熔断参数动态调用相应的功能插件生成各服务框架的标准参数格式,注入到应用中。


组件服务治理的namespace命名: governance

负载均衡/路由(这里可以让用户自由输入ribbon的配制)
 

熔断设计说明:

       基于sping cloud的为基础,抽象出熔断的模型.前端通过界面操作,生成自说明key,保存成kv格式。

       比如sc应用,全局的command对象的execution的timeout的enabled选项参数生成的key值是

hystrix.command.default.execution.timeout.enabled=true;

       对于其他服务框架的配制主要映射到这个模型的相应字段上。
 

参考:

http://support.huaweicloud.com ... .html

https://github.com/ctripcorp/apollo

https://github.com/knightliao/disconf

https://github.com/Qihoo360/QConf


4
问答环节


1、 Q:请问配置中心存储的是配置文件还是key-value? 像数据库连接串之类的信息如何管理的?跟数据连接池怎么配合? 




A:是key-value的,存储在etcd集群上,服务可通过hawk-client拉取配置到服务本地生成本地的配置或直接导入到本地环境变量,这些配置随着服务启动就会生效。




2、 Q:请问Hawk是一个产品吗?




A: Hawk将会是数人云推出的一个企业产品,同时也会作为一个开源项目发布在github上,具体的开源时间我们还不确定,相信很快。




3、 Q:为什么要自己开发一个配置中心,而不是直接使用Spring cloud config?




A:其实很简单,单纯的spring cloud config没有办法充分地切合企业系统的生产需要。我这里有一个功能对比图,大家可以参考一下。










4、Q:请问这个配置中心只能应用于Java语音吗?




      A:配置中心的代码是Java编写的,但是配置中心的使用方,即拉取配置的一方是不限制语言,因为配置拉取是基于http协议。







5、Q:请问数人云的官方网站有关于Hawk这个产品的详细功能介绍吗?今天讲得还是比较快的,希望能具体了解;谢谢。




     A:有的, https://www.shurenyun.com/product-hawk.html







6、 Q:请问CI/CD流程控制是自己研发的还是用的开源方案?




A:CI/CD持续集成,持续交互其实是一个很大的概念,我理解你想问的是Hawk的操作流程以及所使用的技术栈的问题,最初我们参考过其他的一些开源比如携程的appolo,百度的disconf等,结合他们的一些理念,我们又自己总结思考了自己的需求,对CI/CD的业务做出归纳,以达到简单直接的目标,技术方面,我们主要用到spring boot, spring cloud以及etcd等技术,其中spring cloud主要适用于服务注册发现,服务治理等方面。







7、 Q:我想问下,关于配置中心部署问题,第一个,不同环境或者不同集群,你们配置中心是怎么部署的,还有,一些基础组件配置和应用配置放在一个配置中心吗?




A:配置中心通过不同的存储集群,可以实现一个配置中心服务多个环境,但是原则上,建议测试,开发公用一个不熟而生产独立部署,配置中心的中心概念是基于微服务,所以从概念上说,我们的配置是生效于一个服务下的实例级别,而不是组件级别,每个实例下又分为不同的命名空间,命名空间可划分为:应用层,环境变量和自定义的组件,可由客户自定义,所以原则上涵盖了组件与服务的概念。
  查看全部
本文内容来自12月21日 DockOne 微信群线上分享







       微服务近年来炙手可热,如果在后端服务领域诸多热门技术趋势中,比如容器、微服务、DevOps等,找出一个最火的方向,那么非微服务莫属。微服务架构通过有效拆分应用,解耦系统,提供更好的软件伸缩性和企业的敏捷性,实现敏捷开发和部署。





它不是一种横空出世的技术,事实上微服务microservice的概念已经存在多年,一度曾是软件开发的宠儿。近年来被越来越多的企业和开发人员所推崇,并在互联网企业当中大量落地。一些有代表性的传统行业通过实施微服务架构,提高业务灵活性,加速业务需求变化和响应。




       微服务化作为一个体系,包括开发框架、以及周边配套工具链,比如服务治理、配置中心、安全管理、与容器的结合、监控管理等等。往往,围绕微服务的管理体系是微服务搭建的难点所在。




接下我们就谈谈配置中心的架构与实战。





1
为什么需要配置管理中心


       首先,我们的观点是,每一个稍微有点规模的分布式系统,都应该有一个统一配置中心。


当今的系统,随着系统的复杂度增加,配置也日益增多,随着devops等概念的推广,人们对配置的期望值也越来越高:期望配置修改后实时地生效,期望支持灰度发布,发布回滚,历史追踪,环境隔离,集群配置,服务治理等等,这个时候分布式统一配置中心就变得尤为重要。


配置中心解决什么痛点:把业务开发者从复杂以及繁琐的配置中解脱出来,只需专注于业务代码本身,从而能够显著提升开发以及运维效率。同时将配置和发布包解藕也进一步提升发布的成功率,并为运维的细力度管控、应急处理等提供强有力的支持。


配置中心的使用场景:在服务构建阶段,配合构建流水线,为服务软件包或镜像提供配置。

在服务运维阶段,动态调整服务配置,满足运维的灵活性需求。

在服务开发阶段,提供 OpenAPI,为其他基础设施的配置外置化,中心化提供支持。


配置中心Hwk产品需求:  基于上述一些列的特点,我们构思了自己的配置中心的产品需求:

为分布式系统中的基础设施和微服务应用提供集中化的外部配置支持,实现了对服务端和客户端中环境变量,配置文件,动态属性配置的抽象映射,并支持配置的灰度下发,历史版本控制等先进功能

配置接口完全兼容 Spring Cloud Config,后台管理功能则通过 open API的形式对外开放,满足企业多样化的定制需求

管理Springcloud的微服务框架的业务配置,服务治理配置以及kubernetes的configmap和secrets的配置,同时也能通过插件的方式对流行的第三方类库提供特别支持,比如与 sharding-jdbc 的深度集成


2数人云hawk的架构







       配置中心是一个强一致性的系统,配置数据不一致会一起严重的业务问题, Hawk 使用读写分离的方式处理配置数据,Hawk Portal使用mysql 存储配置数据,并把通过审核的配置数据同步给 HawkServer,Hawk Server 使用etcd 来存储并下发的配置数据。认证与授权认证与授权分为 Hawk Portal 和 Hawk Server 两个部分来看。


Hawk Portal在用户使用 Hawk Portal 管理微服务应用和基础设施的配置之前,首选需要使用用户名与密码登录。这是一个简单的 Form based login,目前展示不考虑与企业的认证与授权中心进行单点登录,但需要能够允许用户通过存储在企业 LDAP 中的用户名和密码登录。


Hawk Server对于微服务应用通过 Hawk Client 向 Hawk Server 发起远程调用的时候,无需认证与授权过程,仅做必要的 TLS 对客户端进行身份认证。

当用户通过 Restful API 访问配置服务时,需要对用户的身份进行认证,用户的认证在 API Gateway 上完成而不是配置服务本身。服务发现etcd 同时也为 hawk 提供服务注册于发现的能力,Hawk Portal 与 Hawk Client 都通过 etcd 提供的能力发现和调用 Admin Service与 Config Service。配置存储企业基础设施与微服务应用的配置数据,以及 Hawk 配置中心本身的配置信息首先在 mysql 中落盘,仅当配置数据被激活后,才会同步到 Hawk Server,然后由 Sync Service 落盘到 etcd

领域模型。


集群管理Hawk 可以同时管理多个配置集群,devops 用户可以把不同的集群映射为不同的执行环境,比如开发环境 DEV,功能测试环境 FAT,验收测试环境 UAT等等,使用一套配置中心同时支持多种环境,降低维护成本。


生产环境一般不会与上述环境部署在一起,此时用户可以把配置集群映射到不同的部门,在物理上隔离不同部门的配置数据。

配置集群也可以用于在物理上隔离不同资源的配置,比如区分基础设施(消息中心,调度中心,微服务中心,存储中心)和微服务应用。配置下发微服务应用可以通过Hawk 提供的客户端 SDK Hawk Client 获取配置,也可以通过 Spring Cloud Zuul 服务网管来使用 Config Service 提供的兼容 Spring Cloud Config 的 Restful 接口。

 Hawk 可以通过推送的方式把配置变更直接下发给 Hawk Client ,通过这种方式,配置可以实现实时更新。

Hawk Client 在获取配置信息的同时会连接到配置信息所在的 etcd 集群,并 watch etcd 中的配置配置数据。当 etcd 集群中的配置信息更新后,Hawk Client 将会收到通知。

Hawk Client 提供原生接口允许微服务应用注册监听器监听配置信息的变化服务治理配置中心的配置管理和动态配置下发能力,使得它可以承担服务治理中的 Control Plane 的职责,它可以把服务治理相关的配置下发给实际的执行模块,比如 dubbo,或者是 Spring Cloud 集成的 Netflix 治理工具库,比如 hystrix 以及 ribbon。




服务治理的主要功能包括:

1. 注册/发现:服务实例启动后,将会自动通过 Hawk Client 向配置中心注册,运维可以在配置中心门户查看服务的实例列表,并进行实例级别的服务治理。

2. 负载均衡:调用其他服务时,可以灵活指定其负载均衡策略,如 round robin, hash, consistent hash, weight based round robin 等等。

3. 路由:配置微服务的路由策略和路由规则,路由策略如本地优先,本地数据中心优先等等,路由规则如白名单,黑名单,流量引导,读写分离,前后端分离,灰度升级等等。

4. 限流:针对某个调用方限流对象进行 QPS 限流,分钟级或秒级,或针对所有微服务客户端进行限流。

5. 降级:针对某个降级对象,进行手动或者自动降级(容错),并制定降级策略,抛出异常或特定返回值。

6. 容错:针对某个微服务,设定调用超时与重试策略。

7. 熔断:针对某个微服务或者 RPC方法,设定熔断的触发条件,可以强制熔断,或者自动熔断,也可以取消熔断,运维可以指定熔断参数,比如异常,错误码,失败次数比率,时间窗口,以及窗口请求书等等。3
Hawk基于Spring Cloud的服务治理
系统目标       抽象与具体的服务框架隔离的治理的数据域模型,在系统中均用系统的域模型表示所有的服务治理参数信息,下发到客户端后,能转化成相对应的服务配制信息。


功能分类1. 为其他应用提供服务:注册;

2. 为调用其他应用提供服务:发现和负载均衡;

3. 应用保护自己:熔断并且包含容错,降级。数据流向场景1. 用户在potal上配制a应用要调用的服务b和c,以及a应用的基于Hystrix的熔断配制信息,这些熔断配制可以保存客户端需要的熔断配制信息;

2. a应用启动,hawk client客户端启动;

3. hawk client到server拉取a应用的配制,a应用注册到hawk server;

4. a应用根据配制中的上游服务名b和c,发现提供b和c服务的实例;

5. 根据配制中的负载均衡的算法给每个上游业务配制负载均衡器;

6. 根据配制的熔断参数动态调用相应的功能插件生成各服务框架的标准参数格式,注入到应用中。


组件服务治理的namespace命名: governance

负载均衡/路由(这里可以让用户自由输入ribbon的配制)
 

熔断设计说明:

       基于sping cloud的为基础,抽象出熔断的模型.前端通过界面操作,生成自说明key,保存成kv格式。

       比如sc应用,全局的command对象的execution的timeout的enabled选项参数生成的key值是

hystrix.command.default.execution.timeout.enabled=true;

       对于其他服务框架的配制主要映射到这个模型的相应字段上。
 

参考:

http://support.huaweicloud.com ... .html

https://github.com/ctripcorp/apollo

https://github.com/knightliao/disconf

https://github.com/Qihoo360/QConf


4
问答环节


1、 Q:请问配置中心存储的是配置文件还是key-value? 像数据库连接串之类的信息如何管理的?跟数据连接池怎么配合? 




A:是key-value的,存储在etcd集群上,服务可通过hawk-client拉取配置到服务本地生成本地的配置或直接导入到本地环境变量,这些配置随着服务启动就会生效。




2、 Q:请问Hawk是一个产品吗?




A: Hawk将会是数人云推出的一个企业产品,同时也会作为一个开源项目发布在github上,具体的开源时间我们还不确定,相信很快。




3、 Q:为什么要自己开发一个配置中心,而不是直接使用Spring cloud config?




A:其实很简单,单纯的spring cloud config没有办法充分地切合企业系统的生产需要。我这里有一个功能对比图,大家可以参考一下。










4、Q:请问这个配置中心只能应用于Java语音吗?




      A:配置中心的代码是Java编写的,但是配置中心的使用方,即拉取配置的一方是不限制语言,因为配置拉取是基于http协议。







5、Q:请问数人云的官方网站有关于Hawk这个产品的详细功能介绍吗?今天讲得还是比较快的,希望能具体了解;谢谢。




     A:有的, https://www.shurenyun.com/product-hawk.html







6、 Q:请问CI/CD流程控制是自己研发的还是用的开源方案?




A:CI/CD持续集成,持续交互其实是一个很大的概念,我理解你想问的是Hawk的操作流程以及所使用的技术栈的问题,最初我们参考过其他的一些开源比如携程的appolo,百度的disconf等,结合他们的一些理念,我们又自己总结思考了自己的需求,对CI/CD的业务做出归纳,以达到简单直接的目标,技术方面,我们主要用到spring boot, spring cloud以及etcd等技术,其中spring cloud主要适用于服务注册发现,服务治理等方面。







7、 Q:我想问下,关于配置中心部署问题,第一个,不同环境或者不同集群,你们配置中心是怎么部署的,还有,一些基础组件配置和应用配置放在一个配置中心吗?




A:配置中心通过不同的存储集群,可以实现一个配置中心服务多个环境,但是原则上,建议测试,开发公用一个不熟而生产独立部署,配置中心的中心概念是基于微服务,所以从概念上说,我们的配置是生效于一个服务下的实例级别,而不是组件级别,每个实例下又分为不同的命名空间,命名空间可划分为:应用层,环境变量和自定义的组件,可由客户自定义,所以原则上涵盖了组件与服务的概念。
 

一年4更,如此勤奋的Kuberentes,1.9版更新前瞻

杨y 发表了文章 • 0 个评论 • 203 次浏览 • 2017-12-19 18:14 • 来自相关话题

Kuberentes可谓是2017年风头最劲的编排工具了,随着Kubernetes社区及各大厂商的不断改进、发展,Kuberentes将成为容器管理领域的领导者,昨天,Kubernetes官方发布了本年度第四次也是最后一次新版本的更新公告,即Kuberentes 1.9,那么它都有哪些特性和变化呢?小数今天就带大家看一看~

Kubernetes 1.9

新的“特性”实际上并不是新的,而是基于为了足够稳定生产所使用现有功能的改进,如工作负载的API(DaemonSet、部署ReplicaSet,StatefulSet API),它提供了许多现实环境的基础工作负载,或已经进入到相关的测试阶段,这意味着它们是默认启用的,比如支持Windows服务器的工作负载。

然而只是进入了代码库,例如,Kubernetes 1.9包含了容器存储接口(CSI)和IPv6支持的Alpha实现。

1在升级之前需要做什么

在决定升级到Kuberentes 1.9之前,必须备份Etcd数据,这是非常重要的一件事,因为许多用于部署和升级Kubernetes默认的工具是Etcd3.1,由于Etcd不支持降级,所以如果决定降级Kubernetes部署,那么就无法回到以前的版本,因此虽然可以在不执行备份的情况下升级,但也有一些风险存在。 下面就来了解一下Kubernetes 1.9每个区域的变化细节。

2身份验证和API Machinery

认证和授权访问Kubernetes的过程有了一系列的改进:

首先可以使用集群角色聚合将权限添加到内置的RBAC管理/编辑视图角色中,这些角色适用于整个集群,可以更容易管理谁可以或不能执行某些操作。
此外,授权本身也得到了改进:列如如果一个规则拒绝进入Fires,那么没有理由对链中的其余规则进行评估,这样其他的规则就会被短路。

所有这些都取决于可扩展性,在这个周期中,社区通过添加一种新型的控制Webhook来提高可扩展性。 当试图在Kuberentes中执行操作时,入检查访问和检查名称空间时,接收控制器是发生的不同组件,Webhook使得用户可以通过HTTP POST请求与Kuberentes进行通信;可以发送请求,当某些事件发生时,Kuberentes会进行回调。

在这个版本中,团队致力于“变异”的Webhook,这使得更灵活的进入控制插件得以实现,因为他们让Kuberentes在必要的时候做出改变,允许更大的扩展性。

3定制资源

使用户能够创建自己的“对象”,可以被Kubernetes操纵,同时也已被增强,允许更容易的进行创建和更加可靠。这包括Kubernetes repo中一个新的示例控制器自定义资源定义,以及新的元数据字段选择器、帮助生成代码脚本,以及对已定义资源的验证,用来提高总体解决方案的可靠性。另外,以前的版本只允许引用自定义资源的组,现在可以获得单个实例。

4连网

随着IPv4地址的耗尽,在Kubernetes 1.9中看到对IPv6支持的开始是个好消息。这种支持仍然在Alpha中,并且有很大的局限性,比如缺少双栈支持和没有HostPorts,然而这是一个开始。 此外,随着CoreDNS 1.0的发布,用户可以选择使用它作为kube - dns的替代选择。要安装它,需要CLUSTER_DNS_CORE_DNS为“true”。但是要注意的是这种支持是实验性的,这意味着它可以随时更改或被删除。

其他的网络改进包括- cleanup- ipvs标志,它决定了kube - proxy是否会在启动时刷新所有现有的Ipvs规则(就像它在默认的版本中一样),以及一个新的PodAntiAffinity kube- dns注释来增强恢复力。 用户还可以通过向主机的/ etc/ resolvei添加“选项”来定制pod的DNS客户端的行为。conf或- resolv- conf,这将使它们传播到pod resolve.conf。

5集群生命周期

Federation SIG已经被重命名为集群生命周期,并一直致力于将kubeadm部署工具提高到产品质量。该项目虽然有效,但应用实践相对较短,包括一些新增的alpha特性,比如对CoreDNS的支持、IPv6和动态Kubelet配置。要在配置中安装CoreDNS而不是kube - dns,将CLUSTER_DNS_CORE_DNS设置为“true”。

Kubeadm还获得了一些额外的新特性,例如- print-join- command,这使得在初始集群部署后获得必要的信息以添加新节点,支持Kubelet动态配置,以及将Windows节点添加到集群的能力。

该小组还负责集群API,用于“声明性的kubernet -style API来集群创建、配置和管理”。它提供可选的,可添加的功能,在核心库伯内特斯的顶部。

如果用户正在构建多集群的安装,会很高兴知道kubefed,它允许用户创建一个控制平面来添加、删除和管理联邦集群,已经获得了几个新标志,这些标志可以让用户对它的安装方式和操作方式有更多的控制。- nodeselector标志让用户决定控制器的安装位置,以及添加对- imagepullsecrets和- imageplpolicy的支持,意味着用户现在可以从私有容器注册表中提取图像。

6节点的功能

如果是系统管理员或运维人员,那么Kubernetes 1.9可以使编写配置变得更容易一些,Kubelet的特性门现在表示为KubeletConfiguration中的映射,而不是一串键值对。此外,现在可以设置多个manifest url header,或者使用- manifest-url- header标志或KubeletConfiguration中的manifest . header字段。

而且deviceplugin会一直延伸到更优雅地处理插件设备全生命周期,包括显式cm.GetDevicePluginResourceCapacity()函数,它可以更准确地确定哪些资源是不活跃的,从而使可用资源的更精确的视图。它还确保了设备被正确地移除,即使 kubelet重新启动,并从kubelet传送到设备插件。最后,它确保即使在设备插件删除和 kubelet重新启动之后,预定的pods仍然可以继续运行。

但值得注意的是,根据发布说明,“Kubelet不再从节点状态移除未注册的扩展资源能力;当要自己删除插件时,集群管理员必须手动删除通过设备插件暴露的扩展资源,Kubernetes 1.9包括许多对日志和监视的增强,包括pod级的CPU、内存和本地临时存储。此外,状态摘要网络值,以前只考虑eth0,现在考虑所有的网络接口。

新版本还减轻了一些用户问题,增加了对默认管理和编辑角色的读/写权限,并增加了对podUNK tionbudget的读权限。策略到视图角色。

最后,团队取得了CRI日志解析在pkg/kubelet/apis/cri/logs,所以用户不用纠结于这个手动操作。

7调度

Kubernetes 1.9更改了如何配置kube - scheduler,并向配置文件中添加一个新的- config标志。该文件是Kubernetes期望在未来版本中找到配置值的地方;现在大多数其他的kube调度器标志现在已经被弃用。 此版本还提供了更有效地调度需要扩展资源(如gpu)的工作负载的能力; 调度SIG还完成了一些其他的个别更改,例如在低优先级的pod之前调度更高优先级的pod,以及一个pod能够监听多个IP地址的能力。

8存储

存储在Kubernetes 1.9中的重大更新是添加了容器存储接口(CSI)的alpha实现。CSI是Kubernetes、Docker、Mesosphere和Cloud Foundry社区之间的一个联合项目,它的目的是提供一个单一的API,存储供应商可以在任何支持CSI的编排中实现其产品在“out of the box”中工作。根据Kubernetes存储SIG的说法,“CSI将会像部署一个pod一样轻松地安装新的容量插件,并且允许第三方存储提供商开发他们的插件,而无需将代码添加到核心库伯内特斯代码库中。用户可以通过实例化一个卷作为CSIVolumeSource来使用这个新功能。

存储SIG还增加了几个新功能,包括:

GCE PD、Ceph RBD、AWS EBS和OpenStack Cinder卷的容量大小 体积作为原始块设备(光纤通道仅为Kubernetes 1.9) 可以在容器中运行而不是在主机上运行的工具

9云供应商

Kubernetes 1.9的一个重要变化是,如果用户手动部署Kubernetes,必须为- cloud- provider标志设置一个值;默认情况不再是“自动检测”。允许的选择是:AWS、Azure、Cloudstack、Fake、Gce、Mesos、Openstack、Ovirt、Photon、Rackspace、 Vsphere、以及Unset;自动检测将在Kubernetes 1.10中被移除。(如果用Minikube或Kubeadm之类的工具来安装Kubernetes,不必担心这个问题。) 此外,该版本中的一些更改是针对个别云供应商的。

OpenStack

如果使用OpenStack使用Kubernetes,用户会发现v1.9中的配置要简单得多。自动检测OpenStack服务和版本现在是“只要可行”的规则——在本例中意味着块存储API版本和安全组——用户现在可以将OpenStack负载平衡配置为服务v2提供者。支持OpenStack Octavia v2和中子LBaaS v2。

AWS

AWS的小组(SIG)一直致力于改善Kubernetes与EBS卷的集成。用户将不再使用被调度到“附加”状态的卷的工作负载。相反,节点将被“污染”,以便管理员能够处理问题。团队建议观看这些污染。此外,当停止节点时,卷将自动分离。

此外,Kubernetes现在支持AWS的新NVMe实例类型,以及使用AWS网络负载均衡器,而不是弹性负载均衡器。

Azure

如果用户在Windows上使用Kubernetes,特别是在Azure上,会发现安装卷的失误率更小,因为您现在可以创建Windows挂载路径,并消除驱动器号的需要,这是无限的挂载点。

还可以使用service . beta.kubernetes显式地为公共IP地址设置Azure DNS标签。在使用Azure NSG规则时,仍然能够使用Azure NSG规则,以确保只允许外部访问负载均衡器的IP地址。当更新时,负载均衡器还被增强以考虑更多NSG规则的属性,包括协议、sourceUNK ange和DestinationAddressPrefs。(以前这些字段的更改不会触发更新,因为负载均衡器认识不到已经发生了更改。) Kuberentes 1.9下载地址:https://github.com/kubernetes/ ... 1.9.0

原文作者:Mirantis 原文链接:https://www.tuicool.com/articles/q2EfamA 查看全部
Kuberentes可谓是2017年风头最劲的编排工具了,随着Kubernetes社区及各大厂商的不断改进、发展,Kuberentes将成为容器管理领域的领导者,昨天,Kubernetes官方发布了本年度第四次也是最后一次新版本的更新公告,即Kuberentes 1.9,那么它都有哪些特性和变化呢?小数今天就带大家看一看~

Kubernetes 1.9

新的“特性”实际上并不是新的,而是基于为了足够稳定生产所使用现有功能的改进,如工作负载的API(DaemonSet、部署ReplicaSet,StatefulSet API),它提供了许多现实环境的基础工作负载,或已经进入到相关的测试阶段,这意味着它们是默认启用的,比如支持Windows服务器的工作负载。

然而只是进入了代码库,例如,Kubernetes 1.9包含了容器存储接口(CSI)和IPv6支持的Alpha实现。

1在升级之前需要做什么

在决定升级到Kuberentes 1.9之前,必须备份Etcd数据,这是非常重要的一件事,因为许多用于部署和升级Kubernetes默认的工具是Etcd3.1,由于Etcd不支持降级,所以如果决定降级Kubernetes部署,那么就无法回到以前的版本,因此虽然可以在不执行备份的情况下升级,但也有一些风险存在。 下面就来了解一下Kubernetes 1.9每个区域的变化细节。

2身份验证和API Machinery

认证和授权访问Kubernetes的过程有了一系列的改进:

首先可以使用集群角色聚合将权限添加到内置的RBAC管理/编辑视图角色中,这些角色适用于整个集群,可以更容易管理谁可以或不能执行某些操作。
此外,授权本身也得到了改进:列如如果一个规则拒绝进入Fires,那么没有理由对链中的其余规则进行评估,这样其他的规则就会被短路。

所有这些都取决于可扩展性,在这个周期中,社区通过添加一种新型的控制Webhook来提高可扩展性。 当试图在Kuberentes中执行操作时,入检查访问和检查名称空间时,接收控制器是发生的不同组件,Webhook使得用户可以通过HTTP POST请求与Kuberentes进行通信;可以发送请求,当某些事件发生时,Kuberentes会进行回调。

在这个版本中,团队致力于“变异”的Webhook,这使得更灵活的进入控制插件得以实现,因为他们让Kuberentes在必要的时候做出改变,允许更大的扩展性。

3定制资源

使用户能够创建自己的“对象”,可以被Kubernetes操纵,同时也已被增强,允许更容易的进行创建和更加可靠。这包括Kubernetes repo中一个新的示例控制器自定义资源定义,以及新的元数据字段选择器、帮助生成代码脚本,以及对已定义资源的验证,用来提高总体解决方案的可靠性。另外,以前的版本只允许引用自定义资源的组,现在可以获得单个实例。

4连网

随着IPv4地址的耗尽,在Kubernetes 1.9中看到对IPv6支持的开始是个好消息。这种支持仍然在Alpha中,并且有很大的局限性,比如缺少双栈支持和没有HostPorts,然而这是一个开始。 此外,随着CoreDNS 1.0的发布,用户可以选择使用它作为kube - dns的替代选择。要安装它,需要CLUSTER_DNS_CORE_DNS为“true”。但是要注意的是这种支持是实验性的,这意味着它可以随时更改或被删除。

其他的网络改进包括- cleanup- ipvs标志,它决定了kube - proxy是否会在启动时刷新所有现有的Ipvs规则(就像它在默认的版本中一样),以及一个新的PodAntiAffinity kube- dns注释来增强恢复力。 用户还可以通过向主机的/ etc/ resolvei添加“选项”来定制pod的DNS客户端的行为。conf或- resolv- conf,这将使它们传播到pod resolve.conf。

5集群生命周期

Federation SIG已经被重命名为集群生命周期,并一直致力于将kubeadm部署工具提高到产品质量。该项目虽然有效,但应用实践相对较短,包括一些新增的alpha特性,比如对CoreDNS的支持、IPv6和动态Kubelet配置。要在配置中安装CoreDNS而不是kube - dns,将CLUSTER_DNS_CORE_DNS设置为“true”。

Kubeadm还获得了一些额外的新特性,例如- print-join- command,这使得在初始集群部署后获得必要的信息以添加新节点,支持Kubelet动态配置,以及将Windows节点添加到集群的能力。

该小组还负责集群API,用于“声明性的kubernet -style API来集群创建、配置和管理”。它提供可选的,可添加的功能,在核心库伯内特斯的顶部。

如果用户正在构建多集群的安装,会很高兴知道kubefed,它允许用户创建一个控制平面来添加、删除和管理联邦集群,已经获得了几个新标志,这些标志可以让用户对它的安装方式和操作方式有更多的控制。- nodeselector标志让用户决定控制器的安装位置,以及添加对- imagepullsecrets和- imageplpolicy的支持,意味着用户现在可以从私有容器注册表中提取图像。

6节点的功能

如果是系统管理员或运维人员,那么Kubernetes 1.9可以使编写配置变得更容易一些,Kubelet的特性门现在表示为KubeletConfiguration中的映射,而不是一串键值对。此外,现在可以设置多个manifest url header,或者使用- manifest-url- header标志或KubeletConfiguration中的manifest . header字段。

而且deviceplugin会一直延伸到更优雅地处理插件设备全生命周期,包括显式cm.GetDevicePluginResourceCapacity()函数,它可以更准确地确定哪些资源是不活跃的,从而使可用资源的更精确的视图。它还确保了设备被正确地移除,即使 kubelet重新启动,并从kubelet传送到设备插件。最后,它确保即使在设备插件删除和 kubelet重新启动之后,预定的pods仍然可以继续运行。

但值得注意的是,根据发布说明,“Kubelet不再从节点状态移除未注册的扩展资源能力;当要自己删除插件时,集群管理员必须手动删除通过设备插件暴露的扩展资源,Kubernetes 1.9包括许多对日志和监视的增强,包括pod级的CPU、内存和本地临时存储。此外,状态摘要网络值,以前只考虑eth0,现在考虑所有的网络接口。

新版本还减轻了一些用户问题,增加了对默认管理和编辑角色的读/写权限,并增加了对podUNK tionbudget的读权限。策略到视图角色。

最后,团队取得了CRI日志解析在pkg/kubelet/apis/cri/logs,所以用户不用纠结于这个手动操作。

7调度

Kubernetes 1.9更改了如何配置kube - scheduler,并向配置文件中添加一个新的- config标志。该文件是Kubernetes期望在未来版本中找到配置值的地方;现在大多数其他的kube调度器标志现在已经被弃用。 此版本还提供了更有效地调度需要扩展资源(如gpu)的工作负载的能力; 调度SIG还完成了一些其他的个别更改,例如在低优先级的pod之前调度更高优先级的pod,以及一个pod能够监听多个IP地址的能力。

8存储

存储在Kubernetes 1.9中的重大更新是添加了容器存储接口(CSI)的alpha实现。CSI是Kubernetes、Docker、Mesosphere和Cloud Foundry社区之间的一个联合项目,它的目的是提供一个单一的API,存储供应商可以在任何支持CSI的编排中实现其产品在“out of the box”中工作。根据Kubernetes存储SIG的说法,“CSI将会像部署一个pod一样轻松地安装新的容量插件,并且允许第三方存储提供商开发他们的插件,而无需将代码添加到核心库伯内特斯代码库中。用户可以通过实例化一个卷作为CSIVolumeSource来使用这个新功能。

存储SIG还增加了几个新功能,包括:

GCE PD、Ceph RBD、AWS EBS和OpenStack Cinder卷的容量大小 体积作为原始块设备(光纤通道仅为Kubernetes 1.9) 可以在容器中运行而不是在主机上运行的工具

9云供应商

Kubernetes 1.9的一个重要变化是,如果用户手动部署Kubernetes,必须为- cloud- provider标志设置一个值;默认情况不再是“自动检测”。允许的选择是:AWS、Azure、Cloudstack、Fake、Gce、Mesos、Openstack、Ovirt、Photon、Rackspace、 Vsphere、以及Unset;自动检测将在Kubernetes 1.10中被移除。(如果用Minikube或Kubeadm之类的工具来安装Kubernetes,不必担心这个问题。) 此外,该版本中的一些更改是针对个别云供应商的。

OpenStack

如果使用OpenStack使用Kubernetes,用户会发现v1.9中的配置要简单得多。自动检测OpenStack服务和版本现在是“只要可行”的规则——在本例中意味着块存储API版本和安全组——用户现在可以将OpenStack负载平衡配置为服务v2提供者。支持OpenStack Octavia v2和中子LBaaS v2。

AWS

AWS的小组(SIG)一直致力于改善Kubernetes与EBS卷的集成。用户将不再使用被调度到“附加”状态的卷的工作负载。相反,节点将被“污染”,以便管理员能够处理问题。团队建议观看这些污染。此外,当停止节点时,卷将自动分离。

此外,Kubernetes现在支持AWS的新NVMe实例类型,以及使用AWS网络负载均衡器,而不是弹性负载均衡器。

Azure

如果用户在Windows上使用Kubernetes,特别是在Azure上,会发现安装卷的失误率更小,因为您现在可以创建Windows挂载路径,并消除驱动器号的需要,这是无限的挂载点。

还可以使用service . beta.kubernetes显式地为公共IP地址设置Azure DNS标签。在使用Azure NSG规则时,仍然能够使用Azure NSG规则,以确保只允许外部访问负载均衡器的IP地址。当更新时,负载均衡器还被增强以考虑更多NSG规则的属性,包括协议、sourceUNK ange和DestinationAddressPrefs。(以前这些字段的更改不会触发更新,因为负载均衡器认识不到已经发生了更改。) Kuberentes 1.9下载地址:https://github.com/kubernetes/ ... 1.9.0

原文作者:Mirantis 原文链接:https://www.tuicool.com/articles/q2EfamA

还在为负载均衡操碎心?这里有10大开源负载均衡工具

杨y 发表了文章 • 0 个评论 • 142 次浏览 • 2017-12-15 17:37 • 来自相关话题

关于负载均衡器,小数之前给大家分享了《关于负载均衡和服务发现,Google的经验在这里》数人云工程师手记 | Docker1.12服务发现,负载均衡和Routing Mesh,今天再给大家分享一下十种开源的负载均衡,希望对大家所有帮助。


安装应用程序高可用性和提高性能的最快也最简单的方法之一就是实现负载均衡器(LB)。


在高层次上,有三中类型的负载均衡器,它们分别是:


基于硬件的

基于云计算的

基于软件的



硬件负载均衡器是提供负载均衡的专用设备,一些流行的LB硬件提供商是:



F5

TP-LINK

Barracuda


通常,它们的几个十分昂贵,但性能也非常好。


云端负载均衡器是目前的主要趋势,使用云端负载均衡器是在不投资硬件设备下享受全部功能的一种廉价方法,可以按需付费,以下是一些常用的云端负载均衡器提供商:


AWS

谷歌云

Cloudflare

Incapsula

DigitalOcean

Azure


它们最低的价大约每个月才20美元起。


最后要提到的是软件,可以自行安装管理和配置自己的负载均衡器,它可能是商业版的,也可能是开源的。


如果预算不足,或者想体验免费的负载均衡器解决方案,文本提到的十大开源负载均衡器会有所帮助,欢迎大家转发。



1

Seesaw




它是一个可靠的基于Linux的虚拟负载均衡器服务器,用于在同一网络中提供必要的负载均衡。




Seesaw支持选播,DSR(直接服务器返回),需要两个Seesaw节点,可以是物理的也可以是虚拟的,值得一提的是,Seesaw的工作是第四层网络,所以如果正在寻找七层负载均衡,那么你可以选用下面其他的选项。



2

LoadMaster by KEMP









这是一个免费的高级应用交付控制器,支持所有主要的所有主要的管理程序。 可以下载和使用在数据中心或在AWS和Azure上进行云端部署。


它虽然是免费的,但提供了商业功能,包括:


第四层负载均衡的TCP/UDP使用循环或最少连接算法

Layer 7均衡

内置的WEB应用程序防火墙(WAF)

内置的入侵预防引擎(IPS)

真正的全球服务器负载均衡,支持多站点

缓存内容压缩,内容切换

Web Cookie持久性。

IPSec tunneling



3

HAProxy

它是一个流行于市场提供高可用性,代理,TCP/HTTP负载均衡器,HaProxy为一些世界知名品牌提供服务,如:

Airbnb

GitHub

IMgur

MaxCDN

Reddit

一些功能亮点:

支持IPV6和Unix Socket

压缩和Gzip压缩

健康检查

Source-based session stickiness

内置的统计报告(检测演示)







HAProxy同时也有企业版,硬件和虚拟设备。


4






Zevenet

Zevent支持L3、L4、L7,它可以作为一个源代码,IOS镜像在Docker仓库。

它支持先进的健康检查监控,因此错误的服务器/服务很快就无法运行以提供无缝的用户体验。Zevenet基于TCP的协议,如FTP、HTTP、SIP协议、SSL等。

5






Neutrino

Neutrino支持最少的连接和循环算法,具有以下切换特性:

使用规范的名称

基于上下文

使用TCP端口号

Neutrino测试处理核心VM每秒吞吐量300 +请求。如果与HAProxy相比,然后利用Neutrino的一个主要优点是L7开关。


6

Balance



Balance是一个TCP代理循环负载均衡器,它支持侦听端的IPv6,这意味着可以在后端上使用IPv4.




同时,它也具有所有最基本的负载均衡器特性。



7

PEN


PEN在Linux、FreeBSD、HP-UX、Solaris、Windows上都进行了测试,它支持基于UDP和TCP的协议,如HTTP、SNMP、DNS等。 其中一些特性包括以下基本特性:




GeoIP滤波器

SSL终端

IPv 4,IPv6兼容性

8

Nginx








我知道你可能在想什么。Nginx是一个Web服务器,代理服务器,但是开源的Nginx不支持基本的内容交换和路由请求分配到多个服务器。




然而,Nginx的Plus版比来说:


Nginx Plus是一个全功能的Web应用交付解决方案,包括负载均衡、内容缓存、Web服务器,防火墙,监控等提供了高性能的负载均衡解决方案的规模应用服务请求每秒百万。




9

Traefik

Traefik支持多个后端服务,亚马逊ECS,Docker,Kubernetes等。







它支持Websockets,HTTP / 2,汽车SSL证书更新加密,干净的界面来管理和监控的资源。




10

Gobetween







Gobetween是简约但功能强大的高性能的基于L4 TCP,UDP负载平衡器。




它可以在多个平台如Windows,Linux,Docker上进行工作,达尔文,如果感兴趣可以从源代码建立。均衡是根据在配置中选择的以下算法完成的:







IP hash

World famous – round robin

最小带宽

最少连接




基于这个基准,它的速度要比HAProxy快:







希望上面列出的开源负载均衡器软件会对读者有所帮助,它们都是开源免费的,所以选择最适合自身实际情况的办法就是去进行尝试。 查看全部
关于负载均衡器,小数之前给大家分享了《关于负载均衡和服务发现,Google的经验在这里》数人云工程师手记 | Docker1.12服务发现,负载均衡和Routing Mesh,今天再给大家分享一下十种开源的负载均衡,希望对大家所有帮助。


安装应用程序高可用性和提高性能的最快也最简单的方法之一就是实现负载均衡器(LB)。


在高层次上,有三中类型的负载均衡器,它们分别是:


基于硬件的

基于云计算的

基于软件的



硬件负载均衡器是提供负载均衡的专用设备,一些流行的LB硬件提供商是:



F5

TP-LINK

Barracuda


通常,它们的几个十分昂贵,但性能也非常好。


云端负载均衡器是目前的主要趋势,使用云端负载均衡器是在不投资硬件设备下享受全部功能的一种廉价方法,可以按需付费,以下是一些常用的云端负载均衡器提供商:


AWS

谷歌云

Cloudflare

Incapsula

DigitalOcean

Azure


它们最低的价大约每个月才20美元起。


最后要提到的是软件,可以自行安装管理和配置自己的负载均衡器,它可能是商业版的,也可能是开源的。


如果预算不足,或者想体验免费的负载均衡器解决方案,文本提到的十大开源负载均衡器会有所帮助,欢迎大家转发。



1

Seesaw




它是一个可靠的基于Linux的虚拟负载均衡器服务器,用于在同一网络中提供必要的负载均衡。




Seesaw支持选播,DSR(直接服务器返回),需要两个Seesaw节点,可以是物理的也可以是虚拟的,值得一提的是,Seesaw的工作是第四层网络,所以如果正在寻找七层负载均衡,那么你可以选用下面其他的选项。



2

LoadMaster by KEMP


1.png




这是一个免费的高级应用交付控制器,支持所有主要的所有主要的管理程序。 可以下载和使用在数据中心或在AWS和Azure上进行云端部署。


它虽然是免费的,但提供了商业功能,包括:


第四层负载均衡的TCP/UDP使用循环或最少连接算法

Layer 7均衡

内置的WEB应用程序防火墙(WAF)

内置的入侵预防引擎(IPS)

真正的全球服务器负载均衡,支持多站点

缓存内容压缩,内容切换

Web Cookie持久性。

IPSec tunneling



3

HAProxy

它是一个流行于市场提供高可用性,代理,TCP/HTTP负载均衡器,HaProxy为一些世界知名品牌提供服务,如:

Airbnb

GitHub

IMgur

MaxCDN

Reddit

一些功能亮点:

支持IPV6和Unix Socket

压缩和Gzip压缩

健康检查

Source-based session stickiness

内置的统计报告(检测演示)


2.png


HAProxy同时也有企业版,硬件和虚拟设备。


4

4.png


Zevenet

Zevent支持L3、L4、L7,它可以作为一个源代码,IOS镜像在Docker仓库。

它支持先进的健康检查监控,因此错误的服务器/服务很快就无法运行以提供无缝的用户体验。Zevenet基于TCP的协议,如FTP、HTTP、SIP协议、SSL等。

5

5.png


Neutrino

Neutrino支持最少的连接和循环算法,具有以下切换特性:

使用规范的名称

基于上下文

使用TCP端口号

Neutrino测试处理核心VM每秒吞吐量300 +请求。如果与HAProxy相比,然后利用Neutrino的一个主要优点是L7开关。


6

Balance



Balance是一个TCP代理循环负载均衡器,它支持侦听端的IPv6,这意味着可以在后端上使用IPv4.




同时,它也具有所有最基本的负载均衡器特性。



7

PEN


PEN在Linux、FreeBSD、HP-UX、Solaris、Windows上都进行了测试,它支持基于UDP和TCP的协议,如HTTP、SNMP、DNS等。 其中一些特性包括以下基本特性:




GeoIP滤波器

SSL终端

IPv 4,IPv6兼容性

8

Nginx


5.png



我知道你可能在想什么。Nginx是一个Web服务器,代理服务器,但是开源的Nginx不支持基本的内容交换和路由请求分配到多个服务器。




然而,Nginx的Plus版比来说:


Nginx Plus是一个全功能的Web应用交付解决方案,包括负载均衡、内容缓存、Web服务器,防火墙,监控等提供了高性能的负载均衡解决方案的规模应用服务请求每秒百万。




9

Traefik

Traefik支持多个后端服务,亚马逊ECS,Docker,Kubernetes等。


6.png


它支持Websockets,HTTP / 2,汽车SSL证书更新加密,干净的界面来管理和监控的资源。




10

Gobetween


7.png


Gobetween是简约但功能强大的高性能的基于L4 TCP,UDP负载平衡器。




它可以在多个平台如Windows,Linux,Docker上进行工作,达尔文,如果感兴趣可以从源代码建立。均衡是根据在配置中选择的以下算法完成的:


8.png


IP hash

World famous – round robin

最小带宽

最少连接




基于这个基准,它的速度要比HAProxy快:







希望上面列出的开源负载均衡器软件会对读者有所帮助,它们都是开源免费的,所以选择最适合自身实际情况的办法就是去进行尝试。

一文读懂企业如何落地微服务,循序渐进5步走

杨y 发表了文章 • 0 个评论 • 88 次浏览 • 2017-12-15 17:10 • 来自相关话题

 微服务架构(MSA)正在重塑企业IT生态系统,它最初只是一种机制,将大型单体应用程序分解为一组独立地、功能集中的应用程序,这些应用程序可以独立地设计、开发、测试和部署。MSA的早期采用者运用这种模式来实现其后端系统或业务逻辑,一旦他们实现了这些所谓的后端系统,就有了在整个董事会中实现相同模式的想法,本文主要讨论可以在微服务驱动的企业总可以使用的解决方案模式。
 
01 
 
企业向微服务转型的5步走
 
 
如果从上往下看,企业IT系统看起来就如下图所示:
 

 
如图所示,系统由水平和垂直的多层组成,业务逻辑将在后端系统中作为单片应用程序实现,并且将有像ERP、CRM等第三方系统,在后端系统之上,有一个集成层,将异构后端系统连接在一起,一旦这些服务被集成,就需要通过API管理层作为托管API公开为内部和外部用户的API,安全性和分析将在所有者三层中使用,随着微服务的引入,这个完整的生态系统得到了解决方案模式,可以满足不同企业的需求。
 
 
1
 
MSA(微服务) BE + Monolithic ESB + Monolithic APIM
 
这是微服务实现的最常见和最开始的模式,其中后台系统(业务逻辑)是作为微服务开发的,同时保留其他层。
 

 
上述模式是任何企业引入微服务(MSA)并评估方法利弊的良好七点,基于此方法的结果,可以通过移动到下面提到的模式来实现更广泛的应用。
 
2
 
Monolithic APIM + Service Mesh + 消息代理
 
微服务最新的发展趋势是“服务网格(Service Mesh)”的概念,它提供了微服务间通信所需的附加功能,消息代理(Message Broker)被用作跨微服务的消息交换的通信通道(Dumb Pipe)这将减少在某些用例中集成层的需求。
 

如上图所示,在这个解决方案模式中,MSA已经扩展到了集成层,并消除了单独集成层的需要,尽管这个模式可以在一个绿色的IT企业中实现,但对于拥有这么多附加系统的大型企业来说将会更加困难。
 
3
 
Monolithic APIM + Micro Integration + 服务网格
 
模式2中的一个挑战是将CRM,EPR系统集成到微服务层,与其在微服务层或Message Broker中进行集成,还可以引入一个微集成层来满足这一需求,与此同时,Message Broker功能(消息传递通道)也可以移动到微集成层中。
 

上图可以看到,微服务、数据库系统和COTS系统(ERP、CRM)都是利用微服成层集成的。
 
4
 
服务无网格+微集成+Edge网关
 
随着企业内部的微服务体系结果的广泛采用,Monolithic APIM也可以被微API网关或Edge网关所替代,这是可以实现的下一个解决方案模式。
 

在此模式中,基于向用户公开的API部署了一组Edge网关,从而替换了单一的API管理层,当设计到设计、开发、测试和部署时,这些边缘网关与微服务的行为类似,同时提供API管理功能。
 
5
 
全面转向微服务
 
一旦微服务全面铺开,安全性、分析和数据层也可以作为微服务去实现,除了COTS系统,整个企业IT生态系统作为微服务在这个解决方案模式中实现。
 

基于上图,企业中的所有组件除了第三方系统,都是作为微服务来实现的,这种模式可以扩展,这样服务网格就可以扩展到微集成、分析、安全性和数据库微服务。
 
通过前文我们可以看到,一个企业向微服务转型所经历的是循序渐进的,而不是一蹴而就的,因为尽管开放源码技术,如Docker、Kubernetes、Prometheus和集群使得企业采用微服务架构比以往任何时候都要容易,但让团队在微服务上保持一致仍然是一个困难的挑战。
 
微服务没有本质上的“微”,有些可以很小,但大小是相对的,在企业中没有标准的度量单位,一个公司的“小服务”可能是100万行代码,而在另外一个公司,也许就是1万行。
 
有些人认为微服务根本就不是新出来的概念,而是面向服务的体系结构(SOA)的重新命名,但另外一些人认为微服务是SOA的一个实现,类似于Scrum是如何实现敏捷的。
 
在没有精确定义的情况下,如何让团队在与微服务相同的统一性上?在谈论微服务时,最重要的事情是确保团队以一个共同的起点为基础,模糊的定义不能帮助团队,就如同试图将敏捷实现到实践当中去,却又没有上下文之间的关联关系。
 
 
以下是本文作者关注的三个领域,以及微服务实现中吸取的教训。
 
  

 
团队角度微服务落地思考
 
1
能够更快地使用软件
 
作者的主要应用程序是一个大型的代码库,有几个小团队的开发人员试图为不同的目的构建特性。这意味着每一个改变都必须试图满足所有不同的群体。例如,只提供一个组的数据库更改必须由其他组进行审查和接受,而其他组没有那么多上下文。这很乏味,所以慢了下来。
 
拥有不同的开发人员组共享相同的代码库,这也意味着代码在不经过深思熟虑的情况下会持续地变得更加复杂。当代码库变得更大时,团队中没有人能够拥有它,并确保所有的部件都是有组织的,并以最佳的方式组合在一起。这让部署变得可怕。对应用程序的一行更改需要部署整个代码库,以推动更改。由于部署大型应用程序是高风险的,因此质量保证过程得到了增长,所以部署的更少。
 
通过微服务体系结构,希望能够将代码划分为不同的开发团队,这样开发人员可以完全拥有自己的部分。可以使团队在没有繁琐的设计、审查和部署过程的情况下能够更快地进行创新。希望有更少的开发人员使用更小的代码库,使代码库更容易开发、测试。
 
2
灵活的技术选择
 
作者的主要应用程序是大型的,它与Ruby on Rails建立了一个自定义的JavaScript框架和复杂的构建过程。应用程序的几个部分遇到了主要的性能问题,这些问题很难修复,并导致了应用程序其余部分的问题。后来看到了一个机会,可以使用更好的方法重写应用程序的这些部分。代码库是交织在一起的,这使得重写感觉非常大,而且代价高昂。
 
与此同时,一个前端团队希望从定制JavaScript框架中撤出,并使用新的框架来构建产品特性。但是,对现有的应用程序和复杂的前端构建过程的混合反应似乎很昂贵。
 
随着时间的推移,团队越来越沮丧,因为他们觉得被困在一个太大、太昂贵、无法修复或替换的代码库中。通过采用微服务体系结构,希望保持单个服务的规模更小,意味着用更好的实现来替换它们的成本将更容易管理。也希望能够为每一份工作选择合适的工具,而不是被一刀切的方法所困。可以灵活地在不同的应用程序中使用多种技术。如果一个团队想要使用Ruby以外的其他东西来获得更好的性能,或者从定制的JavaScript框架中切换,都是可以做到的。
 
5
微服务可不是免费的午餐
 
除了概述希望实现的好处之外,还确保对与构建和管理微服务相关的成本和挑战保持清醒,看清现实。开发、托管和管理众多的服务需要大量的开销(并编排了大量不同的开源工具)。在少数几个流程上运行一个单一的代码库,可以很容易地转化成几十个服务的过程,需要负载平衡器、消息传递层和聚类来恢复弹性。管理所有这些需要大量的技能和工具。
 
此外,微服务还涉及到分布式系统,这些系统引入了大量的问题,如网络延迟、容错、事务、不可靠的网络和异步性。
  

 
总结
 
 
一旦定义了微服务的好处和成本,就可以讨论架构,而不会陷入关于谁做的微服务是正确或错误的反效果的争论中。能够更专注于试图解决的核心问题:
 
[list=circle]
[*]
在接下来的6到12个月里,如何让更多的服务更快地帮助我们的软件?[/*]
[*]
在系统中使用特定的工具有很强的技术优势吗?[/*]
[*]
是否预见到想要用更合适的系统替换其中一个系统?[/*]
[*]
当雇佣更多的人的时候,我是如何构建团队的呢?[/*]
[*]
从拥有更多的服务中获得的生产力是否值得可预见的成本?[/*]
[/list]
 
综上所述,这里有5个建议的步骤,可以让团队在进入微服务前进行调整:
[list=circle]
[*]
 [/*]
[*]
了解微服务,同时同意没有“正确”的定义。[/*]
[*]
定义一个共同的目标,以避免适得其反的辩论。[/*]
[*]
讨论并记住采用微服务的预期收益和成本。[/*]
[*]
避免过于急切地想要将微服务一蹴而就,对于如何最好地架构系统,可以接受创造性的想法和热烈的讨论。[/*]
[*]
保持根植于队所发现的利益和成本。[/*]
[/list]
 
其中核心重点是要确保团队有一个明确定义的共同目标来完成,更有价值的是讨论和定义想要实现的微服务,而不是试图确定微服务到底是什么。
 
原文作者:DzoneNodeXperts Blog
原文链接:https://www.tuicool.com/articles/quqeUfN 查看全部
 微服务架构(MSA)正在重塑企业IT生态系统,它最初只是一种机制,将大型单体应用程序分解为一组独立地、功能集中的应用程序,这些应用程序可以独立地设计、开发、测试和部署。MSA的早期采用者运用这种模式来实现其后端系统或业务逻辑,一旦他们实现了这些所谓的后端系统,就有了在整个董事会中实现相同模式的想法,本文主要讨论可以在微服务驱动的企业总可以使用的解决方案模式。
 
01 
 
企业向微服务转型的5步走
 
 
如果从上往下看,企业IT系统看起来就如下图所示:
 

 
如图所示,系统由水平和垂直的多层组成,业务逻辑将在后端系统中作为单片应用程序实现,并且将有像ERP、CRM等第三方系统,在后端系统之上,有一个集成层,将异构后端系统连接在一起,一旦这些服务被集成,就需要通过API管理层作为托管API公开为内部和外部用户的API,安全性和分析将在所有者三层中使用,随着微服务的引入,这个完整的生态系统得到了解决方案模式,可以满足不同企业的需求。
 
 
1
 
MSA(微服务) BE + Monolithic ESB + Monolithic APIM
 
这是微服务实现的最常见和最开始的模式,其中后台系统(业务逻辑)是作为微服务开发的,同时保留其他层。
 

 
上述模式是任何企业引入微服务(MSA)并评估方法利弊的良好七点,基于此方法的结果,可以通过移动到下面提到的模式来实现更广泛的应用。
 
2
 
Monolithic APIM + Service Mesh + 消息代理
 
微服务最新的发展趋势是“服务网格(Service Mesh)”的概念,它提供了微服务间通信所需的附加功能,消息代理(Message Broker)被用作跨微服务的消息交换的通信通道(Dumb Pipe)这将减少在某些用例中集成层的需求。
 

如上图所示,在这个解决方案模式中,MSA已经扩展到了集成层,并消除了单独集成层的需要,尽管这个模式可以在一个绿色的IT企业中实现,但对于拥有这么多附加系统的大型企业来说将会更加困难。
 
3
 
Monolithic APIM + Micro Integration + 服务网格
 
模式2中的一个挑战是将CRM,EPR系统集成到微服务层,与其在微服务层或Message Broker中进行集成,还可以引入一个微集成层来满足这一需求,与此同时,Message Broker功能(消息传递通道)也可以移动到微集成层中。
 

上图可以看到,微服务、数据库系统和COTS系统(ERP、CRM)都是利用微服成层集成的。
 
4
 
服务无网格+微集成+Edge网关
 
随着企业内部的微服务体系结果的广泛采用,Monolithic APIM也可以被微API网关或Edge网关所替代,这是可以实现的下一个解决方案模式。
 

在此模式中,基于向用户公开的API部署了一组Edge网关,从而替换了单一的API管理层,当设计到设计、开发、测试和部署时,这些边缘网关与微服务的行为类似,同时提供API管理功能。
 
5
 
全面转向微服务
 
一旦微服务全面铺开,安全性、分析和数据层也可以作为微服务去实现,除了COTS系统,整个企业IT生态系统作为微服务在这个解决方案模式中实现。
 

基于上图,企业中的所有组件除了第三方系统,都是作为微服务来实现的,这种模式可以扩展,这样服务网格就可以扩展到微集成、分析、安全性和数据库微服务。
 
通过前文我们可以看到,一个企业向微服务转型所经历的是循序渐进的,而不是一蹴而就的,因为尽管开放源码技术,如Docker、Kubernetes、Prometheus和集群使得企业采用微服务架构比以往任何时候都要容易,但让团队在微服务上保持一致仍然是一个困难的挑战。
 
微服务没有本质上的“微”,有些可以很小,但大小是相对的,在企业中没有标准的度量单位,一个公司的“小服务”可能是100万行代码,而在另外一个公司,也许就是1万行。
 
有些人认为微服务根本就不是新出来的概念,而是面向服务的体系结构(SOA)的重新命名,但另外一些人认为微服务是SOA的一个实现,类似于Scrum是如何实现敏捷的。
 
在没有精确定义的情况下,如何让团队在与微服务相同的统一性上?在谈论微服务时,最重要的事情是确保团队以一个共同的起点为基础,模糊的定义不能帮助团队,就如同试图将敏捷实现到实践当中去,却又没有上下文之间的关联关系。
 
 
以下是本文作者关注的三个领域,以及微服务实现中吸取的教训。
 
  

 
团队角度微服务落地思考
 
1
能够更快地使用软件
 
作者的主要应用程序是一个大型的代码库,有几个小团队的开发人员试图为不同的目的构建特性。这意味着每一个改变都必须试图满足所有不同的群体。例如,只提供一个组的数据库更改必须由其他组进行审查和接受,而其他组没有那么多上下文。这很乏味,所以慢了下来。
 
拥有不同的开发人员组共享相同的代码库,这也意味着代码在不经过深思熟虑的情况下会持续地变得更加复杂。当代码库变得更大时,团队中没有人能够拥有它,并确保所有的部件都是有组织的,并以最佳的方式组合在一起。这让部署变得可怕。对应用程序的一行更改需要部署整个代码库,以推动更改。由于部署大型应用程序是高风险的,因此质量保证过程得到了增长,所以部署的更少。
 
通过微服务体系结构,希望能够将代码划分为不同的开发团队,这样开发人员可以完全拥有自己的部分。可以使团队在没有繁琐的设计、审查和部署过程的情况下能够更快地进行创新。希望有更少的开发人员使用更小的代码库,使代码库更容易开发、测试。
 
2
灵活的技术选择
 
作者的主要应用程序是大型的,它与Ruby on Rails建立了一个自定义的JavaScript框架和复杂的构建过程。应用程序的几个部分遇到了主要的性能问题,这些问题很难修复,并导致了应用程序其余部分的问题。后来看到了一个机会,可以使用更好的方法重写应用程序的这些部分。代码库是交织在一起的,这使得重写感觉非常大,而且代价高昂。
 
与此同时,一个前端团队希望从定制JavaScript框架中撤出,并使用新的框架来构建产品特性。但是,对现有的应用程序和复杂的前端构建过程的混合反应似乎很昂贵。
 
随着时间的推移,团队越来越沮丧,因为他们觉得被困在一个太大、太昂贵、无法修复或替换的代码库中。通过采用微服务体系结构,希望保持单个服务的规模更小,意味着用更好的实现来替换它们的成本将更容易管理。也希望能够为每一份工作选择合适的工具,而不是被一刀切的方法所困。可以灵活地在不同的应用程序中使用多种技术。如果一个团队想要使用Ruby以外的其他东西来获得更好的性能,或者从定制的JavaScript框架中切换,都是可以做到的。
 
5
微服务可不是免费的午餐
 
除了概述希望实现的好处之外,还确保对与构建和管理微服务相关的成本和挑战保持清醒,看清现实。开发、托管和管理众多的服务需要大量的开销(并编排了大量不同的开源工具)。在少数几个流程上运行一个单一的代码库,可以很容易地转化成几十个服务的过程,需要负载平衡器、消息传递层和聚类来恢复弹性。管理所有这些需要大量的技能和工具。
 
此外,微服务还涉及到分布式系统,这些系统引入了大量的问题,如网络延迟、容错、事务、不可靠的网络和异步性。
  

 
总结
 
 
一旦定义了微服务的好处和成本,就可以讨论架构,而不会陷入关于谁做的微服务是正确或错误的反效果的争论中。能够更专注于试图解决的核心问题:
 
[list=circle]
[*]
在接下来的6到12个月里,如何让更多的服务更快地帮助我们的软件?[/*]
[*]
在系统中使用特定的工具有很强的技术优势吗?[/*]
[*]
是否预见到想要用更合适的系统替换其中一个系统?[/*]
[*]
当雇佣更多的人的时候,我是如何构建团队的呢?[/*]
[*]
从拥有更多的服务中获得的生产力是否值得可预见的成本?[/*]
[/list]
 
综上所述,这里有5个建议的步骤,可以让团队在进入微服务前进行调整:
[list=circle]
[*]
 [/*]
[*]
了解微服务,同时同意没有“正确”的定义。[/*]
[*]
定义一个共同的目标,以避免适得其反的辩论。[/*]
[*]
讨论并记住采用微服务的预期收益和成本。[/*]
[*]
避免过于急切地想要将微服务一蹴而就,对于如何最好地架构系统,可以接受创造性的想法和热烈的讨论。[/*]
[*]
保持根植于队所发现的利益和成本。[/*]
[/list]
 
其中核心重点是要确保团队有一个明确定义的共同目标来完成,更有价值的是讨论和定义想要实现的微服务,而不是试图确定微服务到底是什么。
 
原文作者:DzoneNodeXperts Blog
原文链接:https://www.tuicool.com/articles/quqeUfN

数人云|别犹豫,8大趋势说明用微服务就对了!

杨y 发表了文章 • 0 个评论 • 89 次浏览 • 2017-12-08 15:22 • 来自相关话题

“微服务”这个关键词随着技术的不断突飞猛进在业内越来越受关注,小数之前给大家分享过很多微服务相关的内容,诸如:《打走企业级落地微服务的拦路虎:数据》《踢开绊脚石:微服务难点之服务调用的解决方案》《实录|微服务企业级落地将会带来哪些转变?》但是你知道对于客户来说,它们最关注微服务的哪些方面吗?2017年秋天,红帽对客户进行一项微服务调查,发现了8个有趣的趋势,今天小数就跟大家分享一下。

01

微服务被用来重新架构现有的应用程序

技术提供商似乎很重视将微服务定位为只用于新项目的市场,然而,调查显示,企业也在使用微服务来重新架构现有和遗留的应用程序。








67%的红帽中间件客户和79%的红帽OpenShift客户反应了这一点,这些数据告诉我们,微服务在他们的IT转型过程中为用户提供了相应的价值——不管他们只是想更新当前的应用程序组合,还是正在准备新的计划。因此,如果只关注微服务的Greenfield项目,那么需要开始评估现有的应用程序进行微服务重新架构可能是一个好注意。微服务引入了一系列已经被证明的利益,不仅适用于新项目,也适用于现有的项目。

2

客户更喜欢多运行时/多技术/多框架的微服务








另外,87%的受访者表示,他们正在使用或考虑多种技术去开发微服务。

因此,若正在使用单一的运行时、技术或框架进行微服务开发,那么不妨开始查看其它运行时、技术和框架,并选择最适合正在尝试解决问题的框架是最明智的选择,换句话说,现在是将单一技术方法扩展多技术方法的最好时机。

3

微服务的六大好处

被调查者发现,他们已经通过微服务获得了很多的好处,位居前六的是:

持续集成(CI)/持续部署(CD)
敏捷性
提高可伸缩性
更快的交付时间
提高开发人员的生产效率
更容易调试和维护







如果对为新项目使用微服务或重新构建现有应用程序而犹豫不决,那就不要再徘徊了,上面的这些好处是用户最关注的问题,而且他们也确确实实得到了相应的好处。

4

微服务效益可以在二至十二个月内实现








正如调查结果所展现的那样,客户可以很快就能开始从微服务中获得收益,为了保持并提高自身的竞争力,当涉及到微服务时,没有道理在一旁犹豫不决,迟迟不能下定决心。

5

实施落地微服务的挑战

正如数人云之前给大家分享线下Meetup中技术大牛演讲中所说的一样,实现微服务其实并不能解决所有问题,它并非灵丹妙药,甚至自身也有极大的挑战,根据报告显示,目前微服务所面临的前四大挑战分别是:

企业文化和组织结构上的挑战
微服务管理
诊断和监控
时间及资源管理







微服务开发需要对软件的开发模式进行转变,对于哪些喜欢现状的企业来说,这首先就是一个挑战,因为他们熟悉当前的流程和过程,此外,还必须学习新的运行时、技术和框架,这也可能对那些不想投资于重新培训他们的劳动力的企业具有一定的挑战性,因为技术与他们的专长不同,如果再培训不是一种好的选择,那么在市场上寻找具有适当经验和背景的资源,可能是另外一个挑战。

随后微服务有两个技术挑战:微服务管理、诊断以及监控,应该在市场上评估可用的解决方案,以提供这些技术挑战的功能,微服务解决方案不断发展,并基于许多最新的创新开发源码技术增加相应功能。

当然除了上述调查中所指出的挑战以外,还有——

确定需要迁移到微服务

在开始将应用程序分解为单个的微服务之前,首先需要了解它的全部范围和架构,这可能很有挑战性,需要使用更全面的视图,但是基于过时的信息,这些信息并不能反映应用程序当前的架构。

需要找到一个解决方案,帮助发现和映射应用程序的每个组件、依赖项和第三方调用,这个解决方案应该帮助了解这些片段的关系,以及它们如何影响应用的行为和用户体验,有了这些信息,就可以清楚地了解需要迁移的内容,并且能够对微服务的架构做出更明智的决定。

确保微服务满足或超过迁移前的性能

为了确保应用程序在迁移后顺利运行,而且用户体验没有受到负面影响,需要一种方法来去比较迁移前后的性能度量,这也许是一件相当困难的事情,因为这两种环境的架构(对硬件的更高和对分布式架构的迁移)可能看起来截然不同,而由独立主机提供商提供的监控工具只提供了整个框架的一小部分,无法创建更全面的数据集,这让事情变得更加困难。

为了解决这些问题,并建立一个一直的基准来衡量您的性能和用户体验,需要在开始迁移之前捕获关键用户交互(通常称为业务事务),在迁移过程中,业务事务可能保持不变,而其他指标可能会随着不同的代码路径和部署在不同的基础设施上而发生变化,使用关于业务事务的基线数据,可以轻松地比较迁移环境前后的性能,并确保对用户体验或整体性能没有影响。

监控新的微服务环境

前文已经提到监控是一大挑战,这里详细说一下,在一些硬件上运行单个代码库的单行单块应用程序,两三个工具就可以提供完整的、直接的对应用程序基础设施性能的监控,然而,随着微服务的引入,以及每个服务为技术堆栈,数据库和托管提供程序实现自己的解决方案的潜力,单个服务现在可能需要比整个应用程序更大量的监控工具,而微服务监控带来了具体的挑战:它们通常很短暂,这意味着在较长的一段时间内,监控可能会更加复杂;而且还会有更多的路径通过服务到达,会暴露出一些问题如线程争用。

最后,虽然开发团队以前不需要一个监控解决方案,但它将基础设施考虑在内,迁移到DevOps和对云原生技术的依赖意味着这个因素不能再被忽视了。

因此要找到一个统一的监控平台,并支持所有的环境,不管是语言还是技术堆栈。这个解决方案必须将来自应用程序和基础结构的度量标准整理成一个真实的来源,并允许这些指标与用户体验相关。

6

克服挑战的四大活动

各企业正在开展相应的办法以应对上面所提出来的各种挑战,受调查者认为,解决这些挑战的前四项办法是:

开发/实施内部Microservices工具
重组
与供应商专家合作/使用供应商作为受信任的顾问
采购或使用微服务平台/解决方案






受访者表示,在微服务方面,他们一直依赖供应商和供应商中小企业作为他们信任的顾问,此外,许多人回应说,重组是一种缓和活动,以克服与企业文化有关的微服务挑战,因此,要在市场上评估微服务解决方案,并选择符合要求的最佳方案,如果解决方案存在漏洞,就在内部实现这些差距,依靠供应商来适应和实施微服务,想要从企业既定流程中激发变更,可能需要重新组建团队,通常引入文化变革和重组,最好先按小的几人团队开始。

7

应用服务器可以用于微服务

因为有了Docker和Kubernetes容器作为一种实现微服务的技术取得了很大的成功。








正如前文所说,企业不只是为新项目应用微服务,也不应用于现有的应用程序,其中许多应用程序是用Java EE使用传统的应用服务器编写的,但并不是所有的应用服务器都是相同的,市场上许多应用服务器都没有实现现代化或重新设计,以满足云原生的开发需求。所以,需要用户自行辨别,选对工具。

如果拥有在Java EE和应用服务器上有着大量经验和专业知识的员工,可以让他们利用经验在现代服务器中开发微服务,保证是在一个多运行时/多技术/多框架的微服务环境中。

8

标准仍然是非常重要

对于开发微服务的客户来说,标准仍然是非常重要的事情。

Red Hat中间件客户使用或考虑使用Java EE进行微服务的三大原因如下:

Java EE是一个标准
无需再去培训员工
Java EE能够运行产品,因为它已经很好地建立了企业级优化







这表明,Red Hat中间件客户看到了开源社区驱动标准和和规范的价值,其旨在运行企业应用程序,并具有可靠性、可用性、可伸缩性和性能(RASP)功能。

原文链接:https://www.tuicool.com/articles/InYzyib 原文作者:Red Hat

数人云·构建灵动新IT 极轻量化PaaS平台 查看全部
“微服务”这个关键词随着技术的不断突飞猛进在业内越来越受关注,小数之前给大家分享过很多微服务相关的内容,诸如:《打走企业级落地微服务的拦路虎:数据》《踢开绊脚石:微服务难点之服务调用的解决方案》《实录|微服务企业级落地将会带来哪些转变?》但是你知道对于客户来说,它们最关注微服务的哪些方面吗?2017年秋天,红帽对客户进行一项微服务调查,发现了8个有趣的趋势,今天小数就跟大家分享一下。

01

微服务被用来重新架构现有的应用程序

技术提供商似乎很重视将微服务定位为只用于新项目的市场,然而,调查显示,企业也在使用微服务来重新架构现有和遗留的应用程序。


1.png



67%的红帽中间件客户和79%的红帽OpenShift客户反应了这一点,这些数据告诉我们,微服务在他们的IT转型过程中为用户提供了相应的价值——不管他们只是想更新当前的应用程序组合,还是正在准备新的计划。因此,如果只关注微服务的Greenfield项目,那么需要开始评估现有的应用程序进行微服务重新架构可能是一个好注意。微服务引入了一系列已经被证明的利益,不仅适用于新项目,也适用于现有的项目。

2

客户更喜欢多运行时/多技术/多框架的微服务


2.png



另外,87%的受访者表示,他们正在使用或考虑多种技术去开发微服务。

因此,若正在使用单一的运行时、技术或框架进行微服务开发,那么不妨开始查看其它运行时、技术和框架,并选择最适合正在尝试解决问题的框架是最明智的选择,换句话说,现在是将单一技术方法扩展多技术方法的最好时机。

3

微服务的六大好处

被调查者发现,他们已经通过微服务获得了很多的好处,位居前六的是:

持续集成(CI)/持续部署(CD)
敏捷性
提高可伸缩性
更快的交付时间
提高开发人员的生产效率
更容易调试和维护

3.png



如果对为新项目使用微服务或重新构建现有应用程序而犹豫不决,那就不要再徘徊了,上面的这些好处是用户最关注的问题,而且他们也确确实实得到了相应的好处。

4

微服务效益可以在二至十二个月内实现


4.png



正如调查结果所展现的那样,客户可以很快就能开始从微服务中获得收益,为了保持并提高自身的竞争力,当涉及到微服务时,没有道理在一旁犹豫不决,迟迟不能下定决心。

5

实施落地微服务的挑战

正如数人云之前给大家分享线下Meetup中技术大牛演讲中所说的一样,实现微服务其实并不能解决所有问题,它并非灵丹妙药,甚至自身也有极大的挑战,根据报告显示,目前微服务所面临的前四大挑战分别是:

企业文化和组织结构上的挑战
微服务管理
诊断和监控
时间及资源管理


5.png


微服务开发需要对软件的开发模式进行转变,对于哪些喜欢现状的企业来说,这首先就是一个挑战,因为他们熟悉当前的流程和过程,此外,还必须学习新的运行时、技术和框架,这也可能对那些不想投资于重新培训他们的劳动力的企业具有一定的挑战性,因为技术与他们的专长不同,如果再培训不是一种好的选择,那么在市场上寻找具有适当经验和背景的资源,可能是另外一个挑战。

随后微服务有两个技术挑战:微服务管理、诊断以及监控,应该在市场上评估可用的解决方案,以提供这些技术挑战的功能,微服务解决方案不断发展,并基于许多最新的创新开发源码技术增加相应功能。

当然除了上述调查中所指出的挑战以外,还有——

确定需要迁移到微服务

在开始将应用程序分解为单个的微服务之前,首先需要了解它的全部范围和架构,这可能很有挑战性,需要使用更全面的视图,但是基于过时的信息,这些信息并不能反映应用程序当前的架构。

需要找到一个解决方案,帮助发现和映射应用程序的每个组件、依赖项和第三方调用,这个解决方案应该帮助了解这些片段的关系,以及它们如何影响应用的行为和用户体验,有了这些信息,就可以清楚地了解需要迁移的内容,并且能够对微服务的架构做出更明智的决定。

确保微服务满足或超过迁移前的性能

为了确保应用程序在迁移后顺利运行,而且用户体验没有受到负面影响,需要一种方法来去比较迁移前后的性能度量,这也许是一件相当困难的事情,因为这两种环境的架构(对硬件的更高和对分布式架构的迁移)可能看起来截然不同,而由独立主机提供商提供的监控工具只提供了整个框架的一小部分,无法创建更全面的数据集,这让事情变得更加困难。

为了解决这些问题,并建立一个一直的基准来衡量您的性能和用户体验,需要在开始迁移之前捕获关键用户交互(通常称为业务事务),在迁移过程中,业务事务可能保持不变,而其他指标可能会随着不同的代码路径和部署在不同的基础设施上而发生变化,使用关于业务事务的基线数据,可以轻松地比较迁移环境前后的性能,并确保对用户体验或整体性能没有影响。

监控新的微服务环境

前文已经提到监控是一大挑战,这里详细说一下,在一些硬件上运行单个代码库的单行单块应用程序,两三个工具就可以提供完整的、直接的对应用程序基础设施性能的监控,然而,随着微服务的引入,以及每个服务为技术堆栈,数据库和托管提供程序实现自己的解决方案的潜力,单个服务现在可能需要比整个应用程序更大量的监控工具,而微服务监控带来了具体的挑战:它们通常很短暂,这意味着在较长的一段时间内,监控可能会更加复杂;而且还会有更多的路径通过服务到达,会暴露出一些问题如线程争用。

最后,虽然开发团队以前不需要一个监控解决方案,但它将基础设施考虑在内,迁移到DevOps和对云原生技术的依赖意味着这个因素不能再被忽视了。

因此要找到一个统一的监控平台,并支持所有的环境,不管是语言还是技术堆栈。这个解决方案必须将来自应用程序和基础结构的度量标准整理成一个真实的来源,并允许这些指标与用户体验相关。

6

克服挑战的四大活动

各企业正在开展相应的办法以应对上面所提出来的各种挑战,受调查者认为,解决这些挑战的前四项办法是:

开发/实施内部Microservices工具
重组
与供应商专家合作/使用供应商作为受信任的顾问
采购或使用微服务平台/解决方案

6.png


受访者表示,在微服务方面,他们一直依赖供应商和供应商中小企业作为他们信任的顾问,此外,许多人回应说,重组是一种缓和活动,以克服与企业文化有关的微服务挑战,因此,要在市场上评估微服务解决方案,并选择符合要求的最佳方案,如果解决方案存在漏洞,就在内部实现这些差距,依靠供应商来适应和实施微服务,想要从企业既定流程中激发变更,可能需要重新组建团队,通常引入文化变革和重组,最好先按小的几人团队开始。

7

应用服务器可以用于微服务

因为有了Docker和Kubernetes容器作为一种实现微服务的技术取得了很大的成功。


7.png



正如前文所说,企业不只是为新项目应用微服务,也不应用于现有的应用程序,其中许多应用程序是用Java EE使用传统的应用服务器编写的,但并不是所有的应用服务器都是相同的,市场上许多应用服务器都没有实现现代化或重新设计,以满足云原生的开发需求。所以,需要用户自行辨别,选对工具。

如果拥有在Java EE和应用服务器上有着大量经验和专业知识的员工,可以让他们利用经验在现代服务器中开发微服务,保证是在一个多运行时/多技术/多框架的微服务环境中。

8

标准仍然是非常重要

对于开发微服务的客户来说,标准仍然是非常重要的事情。

Red Hat中间件客户使用或考虑使用Java EE进行微服务的三大原因如下:

Java EE是一个标准
无需再去培训员工
Java EE能够运行产品,因为它已经很好地建立了企业级优化


8.png


这表明,Red Hat中间件客户看到了开源社区驱动标准和和规范的价值,其旨在运行企业应用程序,并具有可靠性、可用性、可伸缩性和性能(RASP)功能。

原文链接:https://www.tuicool.com/articles/InYzyib 原文作者:Red Hat

数人云·构建灵动新IT 极轻量化PaaS平台