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

杨y 发表了文章 • 0 个评论 • 196 次浏览 • 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 个评论 • 344 次浏览 • 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 个评论 • 265 次浏览 • 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 个评论 • 161 次浏览 • 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 个评论 • 176 次浏览 • 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平台

项目管理多重要,看完本文就知道(程序员,项目经理必看)

杨y 发表了文章 • 0 个评论 • 225 次浏览 • 2017-11-29 14:41 • 来自相关话题

项目管理一直都是项目经理所需要掌握的必备技能,它可以有效的进行整合,以达到高效、高质、低成本的完成企业内部各项工作或项目的目的。近来让项目管理可视化是大家一致在探讨的问题,数人云今天给大家带来的文章将阐述为什么项目管理可视化的重要性,同时开发人员熟练使用项目管理工具可以让其在整个开发生命周期中更好地掌握项目进度。

项目经理与项目管理

可视化项目管理是使用图形、图片、以及图片来显示项目信息。对于那些偏爱于从视觉上获取信息的人,通常会对他们的任务列表进行涂鸦或将其绘制成列表,而那些喜欢创建列表的人则会选择一个有序的任务列表,现在可以看到的是,项目管理工具在满足这两种偏好方面越来越好,并且使得与需要它的人直观地分享信息变得更加容易,如此同时,通过简单的图形可以让其他人更容易掌握自己复杂的想法。

可视化的重要性是什么?

与文字段落相比,在图表上交流复杂的结构或共享数据点要容易很多,从古至今一直如此,今天,技术可以让我们更容易提取所需的数据并且以一种简单易懂的方式呈现出来,方便大家查阅以及阐述想法。








Buzzsumo报道称,视频内容的平均股价上涨了近一倍,而早在2010年,《福布斯》就报道称,视频是高管们的关键信息来源,凸显了以在线视频格式观看业务内容的上升趋势。

基本上,网络正从一个基于文本的环境转变为更多的视觉、图形和视频的环境,这也影响了工作场所的交流。

这对项目经理意味着什么?

与项目经理一起工作的团队成员在其他地方看到不同格式的信息,例如,视频在Facebook上的兴起意味着现在比以前更多的人在消费视频内容,更习惯看到它并搜索它,人们把他们的沟通喜好带到了工作场所。

如果项目的赞助者可以下载一段三分钟关于经济状况的视频,或者是一项复杂的健康研究,他们就会期待同样的信息——提炼成容易消费的数据块——用于他们的项目。

如何在项目中加入视觉传达?

无论是将困难的过程分解成易于遵循的过程图,还是在可视化计划中显示项目进展,都可以通过一些方法共享项目性能数据,从而使您的射中更容易理解消息。

以下是5种“做”视觉项目管理沟通的方法:

1、工作视觉规划工具

无论团队使用的是敏捷方法还是基于瀑布式的方法(或两者混合),都可以考虑您可以与团队成员共享项目进度的方法。

许多项目经理从Gantt图中进行复制和粘贴,并将它们列在项目报告当中,又或许是在一个有日期的表中,考虑一下显示Gantt的卷图版本,或者创建一个具有里程碑跟踪的可视化计划,它只显示关键的里程碑,这是一种比日期列表更有效的共享项目进展的方式。 可以对看板做同样的事情:创建一个显示主要项目步骤和进度的高级版,并在进度报告中包含一个快照。

2、Mindmaps

Mindmapping软件的第一个想法是创意会话和流程,但仍然可以做的更多。

项目需求文档是什么样子的?在一个明确需求的项目中,它可能有很多页的详细说明,Mindmap并没有消除团队拥有所有这些细节的需求,但是需求文档并不是最好的通信工具。

3、项目指示板

指示板的主要用途是用于项目报告,而企业项目管理工具的最大优点是它们能够实现可定制的报告,因此指示板可以反映对涉众重要的内容。

即使团队成员没有相同的指示板访问权限,仍然可以与它们共享数据,要么打印成PDF,然后以电子方式共享,要么接受屏幕截屏并分享图像。

4、照片

照片和截图可以用很多不同的方式使用,即使是在那些输出不是特别上相的项目上。

社交网络对工作方式的另外一个影响是,人们想要更多地与项目背后的个性联系在一起,在工作坊或网站上分享你的团队照片,真的可以让这个项目看起来更真实,这反过来又能提高参与度。

5、视频

如同Jing和Loom这样的工具可以很容易地捕捉和分享短视频,这些都是比较成熟的沟通工具,可以帮助别人知道他们真正想要的是什么,或者快速地展示一个交付物是如何到来的,Lumen5是一个用于为通信创建视频的简单工具,具体教程可参见:https://www.girlsguidetopm.com ... men5/

在简报中包含一个视频链接:如果他们不感兴趣的话,不会点击,但是肯定还是有一些人会去点击查看的。

无论选择哪种提高项目的沟通方式的办法,最重要的是需要考虑这种方法是否对当前的环境有意义?








为什么要转向视觉思维?

当交流方式和视觉上有一个根本性的转变,无论在项目管理软件中充分利用数据可视化工具,还是拿出智能手机捕捉一个团队在一天中发生的事情的视频,重要的是能够与视觉焦点与分享的项目工作。

视觉传播的趋势在这里,就像项目团队采用了“公司”的社交媒体工具一样,项目团队需要采用可视化的思维方式来处理日益增长的期望,即数据也应该被共享。

开发人员与项目管理

不管一个新项目的开始有多么的令人兴奋,开发人员和整个工作团队仍然需要克服许多障碍。随着业务的增长和项目的增加,事情就越容易失控,可能会出现诸多不同的挑战,例如开发人员没有达到预期的目标,被随之而来的工作所淹没最终面临着失败。

针对雄心勃勃的项目开发人员需要关注高质量的工作,并按照计划进行操作,为了确保一切顺利进行,通常会选择一个健壮的、对客户友好的管理系统工具,以划分任务并帮助团队弥合潜在差距,为什么一个可靠的项目管理工具已经成为几乎所有开发者的必备?有以下几个原因:

1、提高团队协作

开发人员使用项目管理软件的一个重要原因是,它最终增加了团队的响应时间和讨论时间,由于开发人员需要关注的事情太多,任何终端都可能对他们的创造力产生破坏性影响,一个好的项目管理工具使团队能够在不打断任何人的情况下,发布“需要知道”的信息,它不仅使团队专注于工作,而且还提高了生产力,并使每个人都处于循环状态,在开发人员、设计师、项目经理和其他团队成员之间建立清晰而间接的沟通是至关重要的,可以避免任何误解和分歧,它使协作在一个地方一直保持并且能看到所有项目相关的信息。

2、与客户直接沟通

虽然项目经理通常充当客户和团队之间的沟通桥梁,但从一开始就让客户参与到项目中似乎是最佳的解决方案,项目管理工具使客户能够看到开发人员和其他团队成员正在工作并提供反馈,如果有一些敏感信息应该保存在团队中,那么它也很容易被隐藏掉,通过这种方式,开发人员和团队的其他成员与客户保持健康和简单的协作与沟通,而不会让客户感到不舒服和不满意,因此不断交流和保持对客户需求信息的定期更新是很重要的。

3、成功的时间追踪

客户主要对最终产品感兴趣,并且不太在意花费在项目开发上的时间,建议开发人员使用最好的项目管理工具,以便为需要额外工作的情况腾出更多的时间,特别是如果客户要求修改和更改,他们需要跟踪所有的支付,协作工具会自动地存储时间记录,这是一个很好的代替时间表和完美的Timesaver,这也证明了在整个过程中花费的时间,并使客户对团队的工作有重要的了解。

4、发票管理更容易

由于在大型项目上工作需要不断的资金流动,所以账单过程应该是快速而简单的,开发人员有时会对支付负责,因为他们需要快速高效的运用。

项目管理工具提供了一个开发项目的发票时间记录的机会,并根据工作类型、任务或项目等不同的类型对它们进行分组,这使得客户更容易在几次点击中查看发票并完成付款,此外,它还能使它们保持良好的组织,并使开发人员能够跟踪整个开发过程。

5、分类复杂的任务

当开始一个项目时,许多开发人员不得不面对它不那么吸引人的部分——项目规划,多个任务需要完成,他们需要一种方法来持续地组织他们的工作,大多数项目管理工具为每个项目都有一个列,根据给定的项目和类别,可以创建不同的任务组,例如:

特性
产品
优先级
复杂性
进度

这样,工作流就变得易于管理以及更加直接,程序员使用项目管理工具的另一个好处是,它在项目时间线报告中概述了所有项目及其任务,帮助开发人员追踪最繁忙的日期,并相应地避免它们。

使用项目管理工具,可以让团队能够分清主次缓急,在的时间点和预算中交付最好的结果,并在让程序员在下一个开发周期更容易地进行开发拥有一个高效的开发工具对实现这一目标有很大的帮助。

小数以前给大家分享过相关的工具,具体可看:

7大ChatOps&5种团队协作工具助力DevOps实践

初伏天,热出5种DevOps事件管理工具

原文作者:The Practical Developer

原文链接:https://www.tuicool.com/articles/RBjYBzY 查看全部
项目管理一直都是项目经理所需要掌握的必备技能,它可以有效的进行整合,以达到高效、高质、低成本的完成企业内部各项工作或项目的目的。近来让项目管理可视化是大家一致在探讨的问题,数人云今天给大家带来的文章将阐述为什么项目管理可视化的重要性,同时开发人员熟练使用项目管理工具可以让其在整个开发生命周期中更好地掌握项目进度。

项目经理与项目管理

可视化项目管理是使用图形、图片、以及图片来显示项目信息。对于那些偏爱于从视觉上获取信息的人,通常会对他们的任务列表进行涂鸦或将其绘制成列表,而那些喜欢创建列表的人则会选择一个有序的任务列表,现在可以看到的是,项目管理工具在满足这两种偏好方面越来越好,并且使得与需要它的人直观地分享信息变得更加容易,如此同时,通过简单的图形可以让其他人更容易掌握自己复杂的想法。

可视化的重要性是什么?

与文字段落相比,在图表上交流复杂的结构或共享数据点要容易很多,从古至今一直如此,今天,技术可以让我们更容易提取所需的数据并且以一种简单易懂的方式呈现出来,方便大家查阅以及阐述想法。


1.png



Buzzsumo报道称,视频内容的平均股价上涨了近一倍,而早在2010年,《福布斯》就报道称,视频是高管们的关键信息来源,凸显了以在线视频格式观看业务内容的上升趋势。

基本上,网络正从一个基于文本的环境转变为更多的视觉、图形和视频的环境,这也影响了工作场所的交流。

这对项目经理意味着什么?

与项目经理一起工作的团队成员在其他地方看到不同格式的信息,例如,视频在Facebook上的兴起意味着现在比以前更多的人在消费视频内容,更习惯看到它并搜索它,人们把他们的沟通喜好带到了工作场所。

如果项目的赞助者可以下载一段三分钟关于经济状况的视频,或者是一项复杂的健康研究,他们就会期待同样的信息——提炼成容易消费的数据块——用于他们的项目。

如何在项目中加入视觉传达?

无论是将困难的过程分解成易于遵循的过程图,还是在可视化计划中显示项目进展,都可以通过一些方法共享项目性能数据,从而使您的射中更容易理解消息。

以下是5种“做”视觉项目管理沟通的方法:

1、工作视觉规划工具

无论团队使用的是敏捷方法还是基于瀑布式的方法(或两者混合),都可以考虑您可以与团队成员共享项目进度的方法。

许多项目经理从Gantt图中进行复制和粘贴,并将它们列在项目报告当中,又或许是在一个有日期的表中,考虑一下显示Gantt的卷图版本,或者创建一个具有里程碑跟踪的可视化计划,它只显示关键的里程碑,这是一种比日期列表更有效的共享项目进展的方式。 可以对看板做同样的事情:创建一个显示主要项目步骤和进度的高级版,并在进度报告中包含一个快照。

2、Mindmaps

Mindmapping软件的第一个想法是创意会话和流程,但仍然可以做的更多。

项目需求文档是什么样子的?在一个明确需求的项目中,它可能有很多页的详细说明,Mindmap并没有消除团队拥有所有这些细节的需求,但是需求文档并不是最好的通信工具。

3、项目指示板

指示板的主要用途是用于项目报告,而企业项目管理工具的最大优点是它们能够实现可定制的报告,因此指示板可以反映对涉众重要的内容。

即使团队成员没有相同的指示板访问权限,仍然可以与它们共享数据,要么打印成PDF,然后以电子方式共享,要么接受屏幕截屏并分享图像。

4、照片

照片和截图可以用很多不同的方式使用,即使是在那些输出不是特别上相的项目上。

社交网络对工作方式的另外一个影响是,人们想要更多地与项目背后的个性联系在一起,在工作坊或网站上分享你的团队照片,真的可以让这个项目看起来更真实,这反过来又能提高参与度。

5、视频

如同Jing和Loom这样的工具可以很容易地捕捉和分享短视频,这些都是比较成熟的沟通工具,可以帮助别人知道他们真正想要的是什么,或者快速地展示一个交付物是如何到来的,Lumen5是一个用于为通信创建视频的简单工具,具体教程可参见:https://www.girlsguidetopm.com ... men5/

在简报中包含一个视频链接:如果他们不感兴趣的话,不会点击,但是肯定还是有一些人会去点击查看的。

无论选择哪种提高项目的沟通方式的办法,最重要的是需要考虑这种方法是否对当前的环境有意义?


2.png



为什么要转向视觉思维?

当交流方式和视觉上有一个根本性的转变,无论在项目管理软件中充分利用数据可视化工具,还是拿出智能手机捕捉一个团队在一天中发生的事情的视频,重要的是能够与视觉焦点与分享的项目工作。

视觉传播的趋势在这里,就像项目团队采用了“公司”的社交媒体工具一样,项目团队需要采用可视化的思维方式来处理日益增长的期望,即数据也应该被共享。

开发人员与项目管理

不管一个新项目的开始有多么的令人兴奋,开发人员和整个工作团队仍然需要克服许多障碍。随着业务的增长和项目的增加,事情就越容易失控,可能会出现诸多不同的挑战,例如开发人员没有达到预期的目标,被随之而来的工作所淹没最终面临着失败。

针对雄心勃勃的项目开发人员需要关注高质量的工作,并按照计划进行操作,为了确保一切顺利进行,通常会选择一个健壮的、对客户友好的管理系统工具,以划分任务并帮助团队弥合潜在差距,为什么一个可靠的项目管理工具已经成为几乎所有开发者的必备?有以下几个原因:

1、提高团队协作

开发人员使用项目管理软件的一个重要原因是,它最终增加了团队的响应时间和讨论时间,由于开发人员需要关注的事情太多,任何终端都可能对他们的创造力产生破坏性影响,一个好的项目管理工具使团队能够在不打断任何人的情况下,发布“需要知道”的信息,它不仅使团队专注于工作,而且还提高了生产力,并使每个人都处于循环状态,在开发人员、设计师、项目经理和其他团队成员之间建立清晰而间接的沟通是至关重要的,可以避免任何误解和分歧,它使协作在一个地方一直保持并且能看到所有项目相关的信息。

2、与客户直接沟通

虽然项目经理通常充当客户和团队之间的沟通桥梁,但从一开始就让客户参与到项目中似乎是最佳的解决方案,项目管理工具使客户能够看到开发人员和其他团队成员正在工作并提供反馈,如果有一些敏感信息应该保存在团队中,那么它也很容易被隐藏掉,通过这种方式,开发人员和团队的其他成员与客户保持健康和简单的协作与沟通,而不会让客户感到不舒服和不满意,因此不断交流和保持对客户需求信息的定期更新是很重要的。

3、成功的时间追踪

客户主要对最终产品感兴趣,并且不太在意花费在项目开发上的时间,建议开发人员使用最好的项目管理工具,以便为需要额外工作的情况腾出更多的时间,特别是如果客户要求修改和更改,他们需要跟踪所有的支付,协作工具会自动地存储时间记录,这是一个很好的代替时间表和完美的Timesaver,这也证明了在整个过程中花费的时间,并使客户对团队的工作有重要的了解。

4、发票管理更容易

由于在大型项目上工作需要不断的资金流动,所以账单过程应该是快速而简单的,开发人员有时会对支付负责,因为他们需要快速高效的运用。

项目管理工具提供了一个开发项目的发票时间记录的机会,并根据工作类型、任务或项目等不同的类型对它们进行分组,这使得客户更容易在几次点击中查看发票并完成付款,此外,它还能使它们保持良好的组织,并使开发人员能够跟踪整个开发过程。

5、分类复杂的任务

当开始一个项目时,许多开发人员不得不面对它不那么吸引人的部分——项目规划,多个任务需要完成,他们需要一种方法来持续地组织他们的工作,大多数项目管理工具为每个项目都有一个列,根据给定的项目和类别,可以创建不同的任务组,例如:

特性
产品
优先级
复杂性
进度

这样,工作流就变得易于管理以及更加直接,程序员使用项目管理工具的另一个好处是,它在项目时间线报告中概述了所有项目及其任务,帮助开发人员追踪最繁忙的日期,并相应地避免它们。

使用项目管理工具,可以让团队能够分清主次缓急,在的时间点和预算中交付最好的结果,并在让程序员在下一个开发周期更容易地进行开发拥有一个高效的开发工具对实现这一目标有很大的帮助。

小数以前给大家分享过相关的工具,具体可看:

7大ChatOps&5种团队协作工具助力DevOps实践

初伏天,热出5种DevOps事件管理工具

原文作者:The Practical Developer

原文链接:https://www.tuicool.com/articles/RBjYBzY

你的编程语言价值几何?2017年15种薪资最高编程语言出炉

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

最近知乎上有一个《为什么很少看到程序员炫富?》的话题火了,看来大家都认同程序员=高薪这种逻辑关系,数人云今天翻阅外网文章看到了一篇2017年15种高薪编程语言,不看不知道,看了吓一跳,虽然国外和国内还是有一些差距的,但是这也表明这些编程语言的薪资报酬上限仍然很高,来看看你所用的语言薪资是多少吧!

2017年薪资最高的15种编程语言

在经济领域和社会领域,科技一直占据着主导的地位,它为数百万人提供了就业的机会,有的人甚至想跨领域去学习技术算计科学、编程以及其他与技术相关的工作,相关的企业也为了寻找到合适的员工提供了相当丰厚的报酬,下列举的这些编程语言即可见一斑:

GO

GO语言的薪资平均在11万美元/年以上,近年来已经高居榜首,09年创建于谷歌的开源开发平台,后如Uber、SondCloud、Netflix、Google和Dropbox都利用了GO语言的元素,实现了内部和基础设施功能。

Scala

熟悉Scala的开发者每年可以获得高达11万美元的收入,不过这还要取决于经验和专业知识,与Java的互通性是Scala的一个关键的特性,因此熟悉这两种开发语言的开发者在寻找工作时会在竞争中占据优势。

Objective-C

Objective-C不仅是一问世时间最久开发者最熟悉的编程语言之一,同时它也非常的赚钱,每年的薪水约在10万美元到 11万美元之间。

CoffeeScript

由于CoffeeScript的可读性和精简性以及能完美转换成JavaScript,使得它在业界广受欢迎,拥有CoffeeScript专业知识的开发者美元收入高达105,000美元。

R

作为一门主要应用于统计计算和图形的开源语言,随着数据驱动分析和预测建模深入到各个行业,R语言也一路水涨船高,平均年薪为10万美元。

TypeScript

TypeScript是一门Microsoft维护的开源编程语言,用于在客户端和服务器端开发JavaScript应用,若能熟练地运用它,大约可以获得10万美元每年的薪资。

SQL

自1974年以来,SQL在四十多年间为成千上万的程序员和数据管理提供了解决方案,如Google、Helix、IBM、Amazon、Microsoft、Oracle等技术巨头至今仍然在继续运用SQL并为其提供了7万到9万美元的年薪。

Java

Java是世界上最流行的编程语言之一,作为客户端—服务器端Web应用程序领域的主要参与者,大约有900万开发人员在使用着Java,如果你是一个Java领域的专家,大约可以获得11.7W美元/年的薪水,普通的Java开发者或许拿不到这么多,但也在7到9万美元之间。

Python

作为一门广受欢迎的通用编程语言,Python的代码可读性和语法的简易性相比于C++或Java可谓是更进一步,Python专家的期望薪水接近9.9万美元。

JavaScript

尽管在过去的几年中,JavaScript的流行度在HTML和CSS的精简版本中大幅度下降,但是大多数现代网站仍然在使用它进行着各种交互,拥有其专业知识的开发者报酬最高达11万美元。

C++

C仍然是一门很重要的编程语言,其通用、快速备受欢迎,哪些在C方面保持专业水平的人可能会拿到年薪9万到10万美元之间的职位。

C#

作为微软.NET框架计划的一个产品,C#仍然是面向对象编程的主流解决方案,它的语法与C++和Java非常相似,但那些具有C#专业知识的程序员每年可以赚到10.7万美元。

Perl

由于Perl的功能强大型和可靠性,它被称为脚本语言中的“瑞士军刀”主要用于管理系统、网络编程、财务和图形用户界面,熟悉Perl语言的人年薪差不多高达11万美元。

PHP

PHP是一门占据着主导地位的编程语言,针对服务器端的Web开发,依赖于C和C++,熟悉这三门编程语言的开发人员能够很容易的就找到一门专注于PHP的高薪工作,薪水可能达到12万美元左右。

IOS/Sift

Swift是近来年发布的最重要的编程语言之一了,苹果将其运用于现代操作系统,如Mac OS和IOS,从事Swift开发的相关人员平均年薪通常高达8万美元,某些高端职位的年薪可能高达12万美元。

当然,以上这些数据报告都是来源于国外,国内与其还有着不少的差距,同时经验与知识度也是衡量一个职位薪水的重要标准,但仍然可以看见其实上述每种语言都有很大的上升空间,需要不断地学习进取,充实自身。 查看全部

微信图片_20171127160629.jpg



最近知乎上有一个《为什么很少看到程序员炫富?》的话题火了,看来大家都认同程序员=高薪这种逻辑关系,数人云今天翻阅外网文章看到了一篇2017年15种高薪编程语言,不看不知道,看了吓一跳,虽然国外和国内还是有一些差距的,但是这也表明这些编程语言的薪资报酬上限仍然很高,来看看你所用的语言薪资是多少吧!

2017年薪资最高的15种编程语言

在经济领域和社会领域,科技一直占据着主导的地位,它为数百万人提供了就业的机会,有的人甚至想跨领域去学习技术算计科学、编程以及其他与技术相关的工作,相关的企业也为了寻找到合适的员工提供了相当丰厚的报酬,下列举的这些编程语言即可见一斑:

GO

GO语言的薪资平均在11万美元/年以上,近年来已经高居榜首,09年创建于谷歌的开源开发平台,后如Uber、SondCloud、Netflix、Google和Dropbox都利用了GO语言的元素,实现了内部和基础设施功能。

Scala

熟悉Scala的开发者每年可以获得高达11万美元的收入,不过这还要取决于经验和专业知识,与Java的互通性是Scala的一个关键的特性,因此熟悉这两种开发语言的开发者在寻找工作时会在竞争中占据优势。

Objective-C

Objective-C不仅是一问世时间最久开发者最熟悉的编程语言之一,同时它也非常的赚钱,每年的薪水约在10万美元到 11万美元之间。

CoffeeScript

由于CoffeeScript的可读性和精简性以及能完美转换成JavaScript,使得它在业界广受欢迎,拥有CoffeeScript专业知识的开发者美元收入高达105,000美元。

R

作为一门主要应用于统计计算和图形的开源语言,随着数据驱动分析和预测建模深入到各个行业,R语言也一路水涨船高,平均年薪为10万美元。

TypeScript

TypeScript是一门Microsoft维护的开源编程语言,用于在客户端和服务器端开发JavaScript应用,若能熟练地运用它,大约可以获得10万美元每年的薪资。

SQL

自1974年以来,SQL在四十多年间为成千上万的程序员和数据管理提供了解决方案,如Google、Helix、IBM、Amazon、Microsoft、Oracle等技术巨头至今仍然在继续运用SQL并为其提供了7万到9万美元的年薪。

Java

Java是世界上最流行的编程语言之一,作为客户端—服务器端Web应用程序领域的主要参与者,大约有900万开发人员在使用着Java,如果你是一个Java领域的专家,大约可以获得11.7W美元/年的薪水,普通的Java开发者或许拿不到这么多,但也在7到9万美元之间。

Python

作为一门广受欢迎的通用编程语言,Python的代码可读性和语法的简易性相比于C++或Java可谓是更进一步,Python专家的期望薪水接近9.9万美元。

JavaScript

尽管在过去的几年中,JavaScript的流行度在HTML和CSS的精简版本中大幅度下降,但是大多数现代网站仍然在使用它进行着各种交互,拥有其专业知识的开发者报酬最高达11万美元。

C++

C仍然是一门很重要的编程语言,其通用、快速备受欢迎,哪些在C方面保持专业水平的人可能会拿到年薪9万到10万美元之间的职位。

C#

作为微软.NET框架计划的一个产品,C#仍然是面向对象编程的主流解决方案,它的语法与C++和Java非常相似,但那些具有C#专业知识的程序员每年可以赚到10.7万美元。

Perl

由于Perl的功能强大型和可靠性,它被称为脚本语言中的“瑞士军刀”主要用于管理系统、网络编程、财务和图形用户界面,熟悉Perl语言的人年薪差不多高达11万美元。

PHP

PHP是一门占据着主导地位的编程语言,针对服务器端的Web开发,依赖于C和C++,熟悉这三门编程语言的开发人员能够很容易的就找到一门专注于PHP的高薪工作,薪水可能达到12万美元左右。

IOS/Sift

Swift是近来年发布的最重要的编程语言之一了,苹果将其运用于现代操作系统,如Mac OS和IOS,从事Swift开发的相关人员平均年薪通常高达8万美元,某些高端职位的年薪可能高达12万美元。

当然,以上这些数据报告都是来源于国外,国内与其还有着不少的差距,同时经验与知识度也是衡量一个职位薪水的重要标准,但仍然可以看见其实上述每种语言都有很大的上升空间,需要不断地学习进取,充实自身。

大会实录|清华徐葳:人工智能让数据中心更好运维

杨y 发表了文章 • 0 个评论 • 235 次浏览 • 2017-11-22 16:59 • 来自相关话题

 
嘉宾介绍:徐葳,清华大学交叉信息研究院助理院长,青年千人学者,博士生导师,UC Berkeley 计算机系 PhD,曾供职于 Google。主要方向为基础架构的监控,日志等,目前以分布式系统以及人工智能等方向为主、包括人工智能、隐私保护、反欺诈等内容。
以下为徐葳在数人云PaaS Innovation 2017,构建灵动新IT大会上的演讲实录。清华大学数据中心运维那点事儿

我(徐葳)显然是个科研人员,同时还管理很多行政事务等,但有些人“命不好”,就是系统管理员的命。所以花了很多时间去管一个IT系统,学院的机房、云平台,基本上夜里大家都睡了,还要登陆上去看看日志,该修点什么就修点什么,我这个人有个毛病,就是看不得机器坏了,看不得什么东西不行,就得马上修好。

清华有系统管理员,就如同我一样都有系统管理员病,很喜欢做系统管理,但他们都是白天上班,因为没有加班费,所以不好意思让人晚上加班,所以晚上一般都由我来管。

这个数据中心做的是人工智能,现在人工智能很热,科研领域清华做的非常前沿,这是最最聪明的应用,但是跑在最最傻的基础架构上。

因为曾经供职于Google,非常想在清华复制一套Google的架构,但这并非一两个人就能开发出来。所以,即便在Google,唯一不能用的地方就是系统运维领域,这是灯下黑,这也是本次讲演的主题叫:“数据中心与智能”。
今天给大家分享几个方面:
首先,数据中心运维,这是和百度合作的一个数据分析的事情,会给大家展示几个有意思的结果。其次,讨论下现在的新架构,Deep Learning深入学习,如何维护这个框架,怎么把数据中心改造成可以进行支持。最后,数据中心现在如此复杂,怎么能再利用一些人工智能的东西放在数据中心里帮助运维。
如何平衡硬件+软件+运维?

首先,这是和百度合作的一件事,百度有很多的机器,有个部门叫硬件运营部,他们收集了很多故障报修,各种产品线,各种不同的产品报修了硬件,硬件运维部就派人去处理一下,大部分处理的方法就是找厂商换新的。所以叫做出了问题的Ticket,几年内积累了29万个,我们可以帮助它的地方是,到底什么东西坏了,拿出来看看,什么时候报修的,大概什么故障,什么部件坏了,这里有很多结果,但因为时间关系,就不挨个赘述了。

报修了一个故障,多长时间会修?如同百度这样管理非常好的公司,报修之后多长时间会有人去处理?不是说修好它,修了不一定能够修好,但至少是去修了,该换什么就换什么,硬盘报错,坏了,就换一个硬盘。

具体时长看起来会非常奇怪:平均需要42天报完错可以修,中位数的修理时间是6.1天,其中有10%的是140天之后仍然没有修,但是没人修并不代表永远都不要这个东西了,过了200天以后仍然有人去处理它,而并没有忘记。
感觉这个时间过长,到底是因为什么?因为机器太多了?又或者系统管理员太忙了?其实未必。

因为如百度、Google这样的公司,系统架构非常容错,硬件出问题是不可避免的,它坏了,既然能容错,就像四个轱辘掉了一个还能跑,为什么要去修呢?所以逻辑是有一个超级容错的系统,在运维时对故障就没有那么敏感。从好的方面来说,可以省钱,因为一次修一个也得跑一趟,修若干个也得跑一趟,因此还不如一次批量的修。
当然硬件损坏无法避免,是否能降低一些容错的复杂性呢?大家目前越来越多的都在讨论这件事,就是三者的平衡,运维的可靠性、软件的成本、硬件的成本之间的三者平衡,现在越来越重要了。

另外,不管如何运维,运维的系统都是非常重要的,任何运维都不是登到界面上去敲几行命令,然后就派出一一件事,这个都是无法做到的,所以不管如何,系统的运维,从一个地方生成这样配置的操作,从一个地方生成的部署,都很重要。
以上讲的是硬件、软件、运维,这三个部分成本如何平衡,现在这个状态下,尤其是大规模的数据中心,有可能和过去小的企业数据中心不同。基于数人云的Docker管理环境

现在深度学习火了,每个人都想要深度学习的机器。最开始一个人要的时候,没关系,从桌面虚拟机集群拆出两台来,装上GPU,自己去用。现在这样的人多了,装了60几块GPU仍然不够,所以这种集群如何共享这60几块GPU,非常麻烦。

后面做了一个什么事情呢?找数人云做GPU虚拟化,虽然GPU支持虚拟化但太贵所以不买,买的都是消费者级别的GPU,因为便宜。当它不支持虚拟化时联合容器,所以将GPU集群上放上了Docker,又找了数人云,帮助开发一个数人云的管理系统,是基于Mesos的开源软件。同时写Mesos的人是我在伯克利的同学,因此对它的印象很好。

将来的就是这样的架构,好处是解决了一个问题,即服务封装,DeepLearning这事真的不复杂,如果你玩过,会发现很简单,其实就是找一个开源的软件框架,上面有很多模型,将其下载下来,都是开源的,这些模型甚至都是训练好的,可以跑人脸识别应用,或者跑其他的什么识别应用,虽然没有专业跑的好,但也不会太差。
但它的问题在于是基于框架,尤其在中国,版本不一样,升级版本升级的特别快,随便动一个升级,其他人都烂了,而不同人就要不同的版本,为什么,因为它下的那个模型是基于某个特定版本开发的,在别的版本上跑不出来,所以在这种情况下,大家去到无数多个配置好的镜像和环境,这个场景挺好,Docker、数人云有它的界面,将这个东西配置好,这种Docker配置的这种Docker,只有这个Docker里面用的是那种版本的东西,因为Docker是一层一层的,不用做那么多镜像,只有一点点区别没有关系,那么多借点有一点点区别,占不了那么多空间,好多镜像,各自用各自的Docker。
所以这解决了一个叫软件分发部署的问题,但有一个问题,总得有训练数据,有点什么东西在里面,完成后改了配置等等,这些东西不可能存回到那个镜像里头去,就想那怎么办呢?可能过了两个星期之后还用呢?所以就不上Docker,留着,等两个星期后再说,但两个星期后做别的项目去了,机器就卡在那里,所以这是个问题,存储它的周边结果存在哪里,是个好大的问题。
简单的方法,有OpenStack,集群上500块硬盘总是有的,挂上NFS,每台机器上面有一个Ceph的NFS,把这些东西对接好,想把这个东西存在那个上面保证安全的,关了以后重启时再挂回来,设计了这样一套存储。
那有什么问题呢?DeepLearning的模型也很大,有些人直接在上面跑,本想让它存储一个备份数据用,跑到上面做一下其实还是存在本地。

所以后来自己改造了存储的架构,做了一个开源项目Alluxio,也是伯克利实验室的一个同学做的。

Alluxio缓存非常有用,它还为Ceph和NFS适配了一个接口,还有Hadoop集群,HDFS里面也有几百块盘,将这三种东西适配城了两个借口,适合放在Docker里面,也适合放在Hadoop里面,且它加了些缓存,这样用机器人内存吸收了很多流量,上图就是大概的基本架构。

HDFS也可以支持,同时也能顺便支持Hadoop,但是如果有一些大的文件,愿意用HDFS的,就用HDFS。

有写机器内存还蛮多的,就是当年趁内存时买了一些内存,还是很有用的,可以将内容缓存住。分布式内存很有意思。用人工智能帮助数据中心运维

最后说一下很多做DeepLearning的程序,这张图片解释了一个词“复杂”,OpenStack觉得自己很干净,为什么?拿个笔都能画出来,但是这张图很复杂,复杂的原因不光是因为有这么多图,凡是看见的都是数据库,数据库是一个持久性的状态,每个组件里都有自己持久的状态,那如怎么保证一致?讨论了这么久分布式系统的一致性,它一旦跨了组件,尤其是跨了开源项目,谁也不会再说这件事。

但若组件坏了,里面还有一个复杂的结构,它一层一层的封装起来,所以什么东西坏了,你可能根本不知道,没坏的时候什么都特别好,但坏了就会很麻烦。
我是个很好的系统管理员,这点特别有信心,但是搞不定这个,因为我不是每天都在配这个,记不得这些东西到底在什么地方,随便查一个什么东西,后面的参数那么长,咱们记不住,但别人天天都在做当然可以记住。

那么,如何能动呢?我们说通过挖掘日志、系统里的状态、跑一些系统里的命令、看一些系统里的数据库,在里面找一些相关的事情,这是纯从样子上找到的,跟语义没有关系。比如ID长那样,那个ID就是ID,IP地址就是IP地址,将这些东西都找在一起,把这些关联性插在一起,就能生成知识图。

另外,为什么三台机器一起坏了,有可能用户只看到一台机器坏了,但其实另外两台也是如此,因为它坏的原因是一个物理机,要坏肯定是三台一起坏,所以都可以找到系统里的一些东西,这有多少个节点?看这个系统看三天,120台物理机不算大,待该有60多个存储的借点,120多个虚拟机的节点,大概出来的结果是几千万个状态,如上图所示,所以可以想象为什么这东西老坏。

最后总结一下,运维是个什么样的过程?刚才说到DevOps,过去的系统管理员如何适应DevOps是一个非常大的挑战,因为DevOps,运维的人是靠开发程序来自动化运维数据中心的,这是必然的趋势,听起来都对。但DevOps推广起来非常难。
DevOps想要推行,一定要把DevOps这些东西的接口配置到过去的系统管理员能懂的那些地方,基本的意思是,预生几个命令行,别说那么多分布式的东西,感觉就是几个配置文件,点点什么东西,这个接口怎么配置,是一个非常大的挑战。
以上是小数整理的徐葳教授在PaaS Innovation 2017上的演讲实录,后台回复“1116”即可下载本次大会的PPT资料。 查看全部
 
嘉宾介绍:徐葳,清华大学交叉信息研究院助理院长,青年千人学者,博士生导师,UC Berkeley 计算机系 PhD,曾供职于 Google。主要方向为基础架构的监控,日志等,目前以分布式系统以及人工智能等方向为主、包括人工智能、隐私保护、反欺诈等内容。
以下为徐葳在数人云PaaS Innovation 2017,构建灵动新IT大会上的演讲实录。清华大学数据中心运维那点事儿

我(徐葳)显然是个科研人员,同时还管理很多行政事务等,但有些人“命不好”,就是系统管理员的命。所以花了很多时间去管一个IT系统,学院的机房、云平台,基本上夜里大家都睡了,还要登陆上去看看日志,该修点什么就修点什么,我这个人有个毛病,就是看不得机器坏了,看不得什么东西不行,就得马上修好。

清华有系统管理员,就如同我一样都有系统管理员病,很喜欢做系统管理,但他们都是白天上班,因为没有加班费,所以不好意思让人晚上加班,所以晚上一般都由我来管。

这个数据中心做的是人工智能,现在人工智能很热,科研领域清华做的非常前沿,这是最最聪明的应用,但是跑在最最傻的基础架构上。

因为曾经供职于Google,非常想在清华复制一套Google的架构,但这并非一两个人就能开发出来。所以,即便在Google,唯一不能用的地方就是系统运维领域,这是灯下黑,这也是本次讲演的主题叫:“数据中心与智能”。
今天给大家分享几个方面:
  • 首先,数据中心运维,这是和百度合作的一个数据分析的事情,会给大家展示几个有意思的结果。
  • 其次,讨论下现在的新架构,Deep Learning深入学习,如何维护这个框架,怎么把数据中心改造成可以进行支持。
  • 最后,数据中心现在如此复杂,怎么能再利用一些人工智能的东西放在数据中心里帮助运维。

如何平衡硬件+软件+运维?

首先,这是和百度合作的一件事,百度有很多的机器,有个部门叫硬件运营部,他们收集了很多故障报修,各种产品线,各种不同的产品报修了硬件,硬件运维部就派人去处理一下,大部分处理的方法就是找厂商换新的。所以叫做出了问题的Ticket,几年内积累了29万个,我们可以帮助它的地方是,到底什么东西坏了,拿出来看看,什么时候报修的,大概什么故障,什么部件坏了,这里有很多结果,但因为时间关系,就不挨个赘述了。

报修了一个故障,多长时间会修?如同百度这样管理非常好的公司,报修之后多长时间会有人去处理?不是说修好它,修了不一定能够修好,但至少是去修了,该换什么就换什么,硬盘报错,坏了,就换一个硬盘。

具体时长看起来会非常奇怪:平均需要42天报完错可以修,中位数的修理时间是6.1天,其中有10%的是140天之后仍然没有修,但是没人修并不代表永远都不要这个东西了,过了200天以后仍然有人去处理它,而并没有忘记。
感觉这个时间过长,到底是因为什么?因为机器太多了?又或者系统管理员太忙了?其实未必。

因为如百度、Google这样的公司,系统架构非常容错,硬件出问题是不可避免的,它坏了,既然能容错,就像四个轱辘掉了一个还能跑,为什么要去修呢?所以逻辑是有一个超级容错的系统,在运维时对故障就没有那么敏感。从好的方面来说,可以省钱,因为一次修一个也得跑一趟,修若干个也得跑一趟,因此还不如一次批量的修。
当然硬件损坏无法避免,是否能降低一些容错的复杂性呢?大家目前越来越多的都在讨论这件事,就是三者的平衡,运维的可靠性、软件的成本、硬件的成本之间的三者平衡,现在越来越重要了。

另外,不管如何运维,运维的系统都是非常重要的,任何运维都不是登到界面上去敲几行命令,然后就派出一一件事,这个都是无法做到的,所以不管如何,系统的运维,从一个地方生成这样配置的操作,从一个地方生成的部署,都很重要。
以上讲的是硬件、软件、运维,这三个部分成本如何平衡,现在这个状态下,尤其是大规模的数据中心,有可能和过去小的企业数据中心不同。基于数人云的Docker管理环境

现在深度学习火了,每个人都想要深度学习的机器。最开始一个人要的时候,没关系,从桌面虚拟机集群拆出两台来,装上GPU,自己去用。现在这样的人多了,装了60几块GPU仍然不够,所以这种集群如何共享这60几块GPU,非常麻烦。

后面做了一个什么事情呢?找数人云做GPU虚拟化,虽然GPU支持虚拟化但太贵所以不买,买的都是消费者级别的GPU,因为便宜。当它不支持虚拟化时联合容器,所以将GPU集群上放上了Docker,又找了数人云,帮助开发一个数人云的管理系统,是基于Mesos的开源软件。同时写Mesos的人是我在伯克利的同学,因此对它的印象很好。

将来的就是这样的架构,好处是解决了一个问题,即服务封装,DeepLearning这事真的不复杂,如果你玩过,会发现很简单,其实就是找一个开源的软件框架,上面有很多模型,将其下载下来,都是开源的,这些模型甚至都是训练好的,可以跑人脸识别应用,或者跑其他的什么识别应用,虽然没有专业跑的好,但也不会太差。
但它的问题在于是基于框架,尤其在中国,版本不一样,升级版本升级的特别快,随便动一个升级,其他人都烂了,而不同人就要不同的版本,为什么,因为它下的那个模型是基于某个特定版本开发的,在别的版本上跑不出来,所以在这种情况下,大家去到无数多个配置好的镜像和环境,这个场景挺好,Docker、数人云有它的界面,将这个东西配置好,这种Docker配置的这种Docker,只有这个Docker里面用的是那种版本的东西,因为Docker是一层一层的,不用做那么多镜像,只有一点点区别没有关系,那么多借点有一点点区别,占不了那么多空间,好多镜像,各自用各自的Docker。
所以这解决了一个叫软件分发部署的问题,但有一个问题,总得有训练数据,有点什么东西在里面,完成后改了配置等等,这些东西不可能存回到那个镜像里头去,就想那怎么办呢?可能过了两个星期之后还用呢?所以就不上Docker,留着,等两个星期后再说,但两个星期后做别的项目去了,机器就卡在那里,所以这是个问题,存储它的周边结果存在哪里,是个好大的问题。
简单的方法,有OpenStack,集群上500块硬盘总是有的,挂上NFS,每台机器上面有一个Ceph的NFS,把这些东西对接好,想把这个东西存在那个上面保证安全的,关了以后重启时再挂回来,设计了这样一套存储。
那有什么问题呢?DeepLearning的模型也很大,有些人直接在上面跑,本想让它存储一个备份数据用,跑到上面做一下其实还是存在本地。

所以后来自己改造了存储的架构,做了一个开源项目Alluxio,也是伯克利实验室的一个同学做的。

Alluxio缓存非常有用,它还为Ceph和NFS适配了一个接口,还有Hadoop集群,HDFS里面也有几百块盘,将这三种东西适配城了两个借口,适合放在Docker里面,也适合放在Hadoop里面,且它加了些缓存,这样用机器人内存吸收了很多流量,上图就是大概的基本架构。

HDFS也可以支持,同时也能顺便支持Hadoop,但是如果有一些大的文件,愿意用HDFS的,就用HDFS。

有写机器内存还蛮多的,就是当年趁内存时买了一些内存,还是很有用的,可以将内容缓存住。分布式内存很有意思。用人工智能帮助数据中心运维

最后说一下很多做DeepLearning的程序,这张图片解释了一个词“复杂”,OpenStack觉得自己很干净,为什么?拿个笔都能画出来,但是这张图很复杂,复杂的原因不光是因为有这么多图,凡是看见的都是数据库,数据库是一个持久性的状态,每个组件里都有自己持久的状态,那如怎么保证一致?讨论了这么久分布式系统的一致性,它一旦跨了组件,尤其是跨了开源项目,谁也不会再说这件事。

但若组件坏了,里面还有一个复杂的结构,它一层一层的封装起来,所以什么东西坏了,你可能根本不知道,没坏的时候什么都特别好,但坏了就会很麻烦。
我是个很好的系统管理员,这点特别有信心,但是搞不定这个,因为我不是每天都在配这个,记不得这些东西到底在什么地方,随便查一个什么东西,后面的参数那么长,咱们记不住,但别人天天都在做当然可以记住。

那么,如何能动呢?我们说通过挖掘日志、系统里的状态、跑一些系统里的命令、看一些系统里的数据库,在里面找一些相关的事情,这是纯从样子上找到的,跟语义没有关系。比如ID长那样,那个ID就是ID,IP地址就是IP地址,将这些东西都找在一起,把这些关联性插在一起,就能生成知识图。

另外,为什么三台机器一起坏了,有可能用户只看到一台机器坏了,但其实另外两台也是如此,因为它坏的原因是一个物理机,要坏肯定是三台一起坏,所以都可以找到系统里的一些东西,这有多少个节点?看这个系统看三天,120台物理机不算大,待该有60多个存储的借点,120多个虚拟机的节点,大概出来的结果是几千万个状态,如上图所示,所以可以想象为什么这东西老坏。

最后总结一下,运维是个什么样的过程?刚才说到DevOps,过去的系统管理员如何适应DevOps是一个非常大的挑战,因为DevOps,运维的人是靠开发程序来自动化运维数据中心的,这是必然的趋势,听起来都对。但DevOps推广起来非常难。
DevOps想要推行,一定要把DevOps这些东西的接口配置到过去的系统管理员能懂的那些地方,基本的意思是,预生几个命令行,别说那么多分布式的东西,感觉就是几个配置文件,点点什么东西,这个接口怎么配置,是一个非常大的挑战。
以上是小数整理的徐葳教授在PaaS Innovation 2017上的演讲实录,后台回复“1116”即可下载本次大会的PPT资料。

微服务架构企业级增强产品:数人云推出统一配置中心Hawk

杨y 发表了文章 • 0 个评论 • 277 次浏览 • 2017-11-22 16:58 • 来自相关话题

11月16日,数人云在PaaS Innovation大会上,正式发布企业应用架构管理体系EAMS,这是数人云轻量化PaaS平台的重要产品体系,也是数人云向微服务方向延伸,践行微服务落地的战略调整。传统企业对微服务应用的管理需求日益强烈,微服务也成为云计算原生应用的标准开发框架,是落地敏捷开发和部署的关键。如今,EAMS产品家族又多了一位核心成员——数人云统一配置中心Hawk。

互联网企业和传统金融等行业具有业务配置复杂,配置数据量大,配置容易出错等特点,如何能将配置数据与程序包解耦,避免对环境的依赖成为一大难点。特别是引入微服务后,业务配置数量急剧增加,出错概率也同步增加,如果能统一管控,支持多环境管理成为运维的一大难点和痛点。

基于微服务理念打造的分布式统一配置中心Hawk支持多种类型配置如Spring Cloud、Dubbo、Kubernetes Configmap、Logback、Linux Environment等等,具有完善的配置管理流程、配置实时推送、支持多集群多环境、多版本控制,更提供配置细力度的管理如灰度管理、任意版本重置等丰富功能。整个体系兼容开源社区的Spring Cloud Config以及Kubernetes的Configmap,极大降低使用者的学习门槛以及降低业务对于平台的耦合。相应的管理流程也规范了配置的使用和降低因为配置带来的发布错误等。

Hawk的主体架构








在功能方面,数人云分布式统一调度平台Hawk具备完善的企业级功能:

配置流程管理:完善的配置流程管理,确保配置下发前必须获得确认和授权。
认证与授权:提供 LDAP 集成,以及多角色权限管理。
支持操作审计:确保配置操作有据可查。
支持多种配置文件:支持Spring Cloud Config、Dubbo、Logback、Linux Environment、Nginx、Tomcat等等,并持续增加中。
支持Spring Cloud服务治理配置和管控:支持Spring Cloud自有的Hystrix的微服务治理如熔断、Fallback等等。
无缝集成 Kubernetes 的 Configmap 以及 Secrets:无缝集成 Kubernetes 的 Configmap 以及 Secrets 的配置管理,并提供增强的企业管理流程。
支持配置实时推送以及实时生效:配置变更能触发应用实时生效,避免应用重启来激活配置,从而降低服务中断的风险。
支持多版本管理:支持多版本管理,并支持历史版本的激活。
支持多配置集群、多环境配置。
优美的监控台:提供多维度 Dashboard 以及监控视图,支持配置灰度和回滚。
支持配置灰度和回滚。
支持数据全局备份和恢复:进一步提升配置数据的容灾能力
提供OpenAPI:支持多系统集成的便利手段、支持配置应急预案处理






数人云的轻量级PaaS平台,在容器平台的基础上延伸出丰富的产品线,致力于成为云时代的新PaaS,为客户快速打造互联网应用的系统和架构支持。在开发以及运维层面,分布式统一配置中心Hawk是EAMS体系的进一步增强。据悉,数人云EAMS体系下,一系列开发管理框架以及智能管理工具尚在持续研发中,以期帮助客户降低运维难度和复杂度,快速应对业务迭代,帮助客户构建敏捷IT能力。 查看全部

1.png



11月16日,数人云在PaaS Innovation大会上,正式发布企业应用架构管理体系EAMS,这是数人云轻量化PaaS平台的重要产品体系,也是数人云向微服务方向延伸,践行微服务落地的战略调整。传统企业对微服务应用的管理需求日益强烈,微服务也成为云计算原生应用的标准开发框架,是落地敏捷开发和部署的关键。如今,EAMS产品家族又多了一位核心成员——数人云统一配置中心Hawk。

互联网企业和传统金融等行业具有业务配置复杂,配置数据量大,配置容易出错等特点,如何能将配置数据与程序包解耦,避免对环境的依赖成为一大难点。特别是引入微服务后,业务配置数量急剧增加,出错概率也同步增加,如果能统一管控,支持多环境管理成为运维的一大难点和痛点。

基于微服务理念打造的分布式统一配置中心Hawk支持多种类型配置如Spring Cloud、Dubbo、Kubernetes Configmap、Logback、Linux Environment等等,具有完善的配置管理流程、配置实时推送、支持多集群多环境、多版本控制,更提供配置细力度的管理如灰度管理、任意版本重置等丰富功能。整个体系兼容开源社区的Spring Cloud Config以及Kubernetes的Configmap,极大降低使用者的学习门槛以及降低业务对于平台的耦合。相应的管理流程也规范了配置的使用和降低因为配置带来的发布错误等。

Hawk的主体架构


2.png



在功能方面,数人云分布式统一调度平台Hawk具备完善的企业级功能:

配置流程管理:完善的配置流程管理,确保配置下发前必须获得确认和授权。
认证与授权:提供 LDAP 集成,以及多角色权限管理。
支持操作审计:确保配置操作有据可查。
支持多种配置文件:支持Spring Cloud Config、Dubbo、Logback、Linux Environment、Nginx、Tomcat等等,并持续增加中。
支持Spring Cloud服务治理配置和管控:支持Spring Cloud自有的Hystrix的微服务治理如熔断、Fallback等等。
无缝集成 Kubernetes 的 Configmap 以及 Secrets:无缝集成 Kubernetes 的 Configmap 以及 Secrets 的配置管理,并提供增强的企业管理流程。
支持配置实时推送以及实时生效:配置变更能触发应用实时生效,避免应用重启来激活配置,从而降低服务中断的风险。
支持多版本管理:支持多版本管理,并支持历史版本的激活。
支持多配置集群、多环境配置。
优美的监控台:提供多维度 Dashboard 以及监控视图,支持配置灰度和回滚。
支持配置灰度和回滚。
支持数据全局备份和恢复:进一步提升配置数据的容灾能力
提供OpenAPI:支持多系统集成的便利手段、支持配置应急预案处理

3.png


数人云的轻量级PaaS平台,在容器平台的基础上延伸出丰富的产品线,致力于成为云时代的新PaaS,为客户快速打造互联网应用的系统和架构支持。在开发以及运维层面,分布式统一配置中心Hawk是EAMS体系的进一步增强。据悉,数人云EAMS体系下,一系列开发管理框架以及智能管理工具尚在持续研发中,以期帮助客户降低运维难度和复杂度,快速应对业务迭代,帮助客户构建敏捷IT能力。

演讲实录 | 招银云创:容器PaaS正在让开发人员再也看不到IaaS

杨y 发表了文章 • 0 个评论 • 252 次浏览 • 2017-11-20 18:46 • 来自相关话题

嘉宾介绍:陈沙克,招银云创战略研究院总监,从2010年开始从事云计算相关工作,做OpenStack七年有余,目前在招银云创负责PaaS相关工作。此文为陈沙克在数人云PaaS Innovation 2017,构建灵动新IT大会上的演讲实录。

招银云创是招商银行的全资子公司,代表招商银行进行科技的输出,致力于将招行30年的经验和技术积累输出给广大金融企业,帮助同业同行快速的金融创新。

容器快速交付提高金融的互联网化

金融行业特性与其他行业在思维方式上有很大不同。

金融是强监管行业,尝试新技术面临监管的要求。那么,强监管下如何跟上变化的需要呢?这里面展开可以有很多故事。在Fintech互联网金融影响下,银行在监管上其实有所放松。其次,银行业有非常严格的安全性要求。由于历史原因,银行内部IT系统非常复杂,通常每家银行都有上百个系统。








中国的银行体系非常庞大,这可能跟金融行业外朋友的感知不同。这些银行包括农村信用社、农村银行、城市商业银行等,他们都有巨大的IT系统托管需求。招银云创就是服务以上这些客户。








随着银行业务的发展,之前系统托管和所服务的客户都是场地托管,系统灵活性不足。但随着互联网以及业务的发展,客户开始提出一些定制化的需求,对银行业务的开展产生巨大挑战。








互联网化的金融IT需求如何应对?客户定制化需求如何满足?金融行业云在互联网金融汹涌来袭的背景下,面临巨大挑战。有同行强调,银行要做金融的互联网,而不能由互联网来主导金融。其实,今天在金融行业的人都应该有这个想法。

招银云创PaaS平台希望将各种行业的应用放在PaaS平台上,帮助企业更快地落地。假如银行有100多个项目同时开发,对于前面提到的大多数银行来讲是不现实的,希望有一个平台能帮助企业实现快速交付。

如何才能做到快速交付?招银云创认为,只有标准化形成规模,才能够将很多东西以一种标准化的形式提供出去,同时也要满足企业未来发展的需求。容器就是一种在标准化和简单化之间找到平衡的技术。








成熟的容器正在让开发人员再也看不到IaaS

现在简单介绍一下招银云创PaaS平台的架构。对于银行来说,金融行业全部应用都是基于JAVA来开发。但现在,新的应用都要求基于Spring Cloud框架来开发,只有用Spring Cloud框架开发,放在PaaS平台上才能体现出优势。容器的管理平台现在已经比较成熟。Kubernetes在新一轮的编排工具大战中胜出,但仅仅一个Kubernetes满足不了金融PaaS的需求,容器周边还需要诸多辅助系统,从而让开发和运维人员更好地使用。







在过去的两个多月,招银云创一直在推动将自己的Spring Cloud应用迁移到PaaS平台。这次迁移团队也积累了很多经验和教训。

首先,配置管理。Spring Cloud的配置管理是用git来管理的。当把应用搬到PaaS平台上时,运维人员会向开发人员提出配置管理的要求,比如要求开发人员对配置要统一管理,不能到处放置配置文件。








开发人员很乐意接受这个建议。以往推PaaS平台时,对开发人员的工作改动量很大。现在,新的PaaS平台开发人员感受到的,不是改动多少代码,而是带来多少便利,以及给出很合理的需求。

招银云创希望在整个Spring Cloud里面配置管理,不仅可以用Git管理,而且开发自己的配置管理中心来完善PaaS平台。

日志管理向来复杂,银行的日志则会更加复杂。原因在于,日志含有大量交易信息,这些信息不仅需要保留,而且要检索。除了系统日志,还包含应用的日志,应用日志量非常庞大,甚至达到每天T级别的日志量,尤其采用微服务后。那么,这些日志应该如何处理呢?













招银云创希望日志管理简单化。对于传统的金融行业来讲,技术没有那么丰富,采用的技术眼花缭乱任何团队想完全Hold住都有压力。招银云创同时希望日志标准化,实现日志的统一管理。招银云创的应用多是自己开发,对应用的日志输出做出要求,这样整个PaaS平台能够真正用起来。

如今,监控已不像以前那么眼花缭乱,Prometheus也实现了一统江湖。加之官方的展示,基本满足招银对监控屏展示的要求。








持续集成则跟开发密切相关。以前在做OpenStack时,经常谈到怎么用OpenStack虚拟机来做持续集成,那个过程很痛苦。因为虚拟机的启动、安装、部署代价非常高,持续时间周期很长。在OpenStack上做开发,如果要跑一两个小时才能出结果,这在传统企业是根本无法接受的。采用容器的CI以后,这种局面得到彻底改观。所有的提交以及镜像发布到测试,可以做到分钟级解决。借助各种内网的源,整个镜像和发布过程很快。







对于新的PaaS平台来说,重点工作之一是通过发布管理去发布。PaaS平台偏运维,在招银云创内部,运维人员能够深切地感受到对自身带来的巨大帮助,以前纯手工的过程全部自动化完成。在过去的两个月,招银云创内部推动PaaS平台积极性最高的也是运维人员,实现了从手工到完全自动化,甚至智能化。招银云创已经做到代码一提交,马上去做镜像,然后推送到发布的一体化流程,这在以往不可想象。在没有容器之前,哪怕采用Spring Cloud开发应用,也无法发挥它的特点。







回到镜像管理,镜像管理能够看到很多方案,但对企业来说,镜像积累到一定程度,变成企业的资产,日后有可能代替电子仓库。云创镜像积累的很好,一些不同版本都能够得到快速满足,实现快速迭代,满足开发需求。







经过两个月PaaS平台的使用,运维人员感触最深的是“开发人员已经看不到IaaS平台了”。为什么这么说?以前开发人员经常要在IaaS平台里面启动各种虚拟机,来进行测试、完善。用了PaaS平台后,开发、发布、交付生产线,都已经不需要关注底层是虚拟机还是物理机,只需要关注一个PaaS平台。





  查看全部

1.png



嘉宾介绍:陈沙克,招银云创战略研究院总监,从2010年开始从事云计算相关工作,做OpenStack七年有余,目前在招银云创负责PaaS相关工作。此文为陈沙克在数人云PaaS Innovation 2017,构建灵动新IT大会上的演讲实录。

招银云创是招商银行的全资子公司,代表招商银行进行科技的输出,致力于将招行30年的经验和技术积累输出给广大金融企业,帮助同业同行快速的金融创新。

容器快速交付提高金融的互联网化

金融行业特性与其他行业在思维方式上有很大不同。

金融是强监管行业,尝试新技术面临监管的要求。那么,强监管下如何跟上变化的需要呢?这里面展开可以有很多故事。在Fintech互联网金融影响下,银行在监管上其实有所放松。其次,银行业有非常严格的安全性要求。由于历史原因,银行内部IT系统非常复杂,通常每家银行都有上百个系统。


2.png



中国的银行体系非常庞大,这可能跟金融行业外朋友的感知不同。这些银行包括农村信用社、农村银行、城市商业银行等,他们都有巨大的IT系统托管需求。招银云创就是服务以上这些客户。


3.png



随着银行业务的发展,之前系统托管和所服务的客户都是场地托管,系统灵活性不足。但随着互联网以及业务的发展,客户开始提出一些定制化的需求,对银行业务的开展产生巨大挑战。


4.png



互联网化的金融IT需求如何应对?客户定制化需求如何满足?金融行业云在互联网金融汹涌来袭的背景下,面临巨大挑战。有同行强调,银行要做金融的互联网,而不能由互联网来主导金融。其实,今天在金融行业的人都应该有这个想法。

招银云创PaaS平台希望将各种行业的应用放在PaaS平台上,帮助企业更快地落地。假如银行有100多个项目同时开发,对于前面提到的大多数银行来讲是不现实的,希望有一个平台能帮助企业实现快速交付。

如何才能做到快速交付?招银云创认为,只有标准化形成规模,才能够将很多东西以一种标准化的形式提供出去,同时也要满足企业未来发展的需求。容器就是一种在标准化和简单化之间找到平衡的技术。


5.png



成熟的容器正在让开发人员再也看不到IaaS

现在简单介绍一下招银云创PaaS平台的架构。对于银行来说,金融行业全部应用都是基于JAVA来开发。但现在,新的应用都要求基于Spring Cloud框架来开发,只有用Spring Cloud框架开发,放在PaaS平台上才能体现出优势。容器的管理平台现在已经比较成熟。Kubernetes在新一轮的编排工具大战中胜出,但仅仅一个Kubernetes满足不了金融PaaS的需求,容器周边还需要诸多辅助系统,从而让开发和运维人员更好地使用。

6.png



在过去的两个多月,招银云创一直在推动将自己的Spring Cloud应用迁移到PaaS平台。这次迁移团队也积累了很多经验和教训。

首先,配置管理。Spring Cloud的配置管理是用git来管理的。当把应用搬到PaaS平台上时,运维人员会向开发人员提出配置管理的要求,比如要求开发人员对配置要统一管理,不能到处放置配置文件。


7.png



开发人员很乐意接受这个建议。以往推PaaS平台时,对开发人员的工作改动量很大。现在,新的PaaS平台开发人员感受到的,不是改动多少代码,而是带来多少便利,以及给出很合理的需求。

招银云创希望在整个Spring Cloud里面配置管理,不仅可以用Git管理,而且开发自己的配置管理中心来完善PaaS平台。

日志管理向来复杂,银行的日志则会更加复杂。原因在于,日志含有大量交易信息,这些信息不仅需要保留,而且要检索。除了系统日志,还包含应用的日志,应用日志量非常庞大,甚至达到每天T级别的日志量,尤其采用微服务后。那么,这些日志应该如何处理呢?


8.png


9.png



招银云创希望日志管理简单化。对于传统的金融行业来讲,技术没有那么丰富,采用的技术眼花缭乱任何团队想完全Hold住都有压力。招银云创同时希望日志标准化,实现日志的统一管理。招银云创的应用多是自己开发,对应用的日志输出做出要求,这样整个PaaS平台能够真正用起来。

如今,监控已不像以前那么眼花缭乱,Prometheus也实现了一统江湖。加之官方的展示,基本满足招银对监控屏展示的要求。


10.png



持续集成则跟开发密切相关。以前在做OpenStack时,经常谈到怎么用OpenStack虚拟机来做持续集成,那个过程很痛苦。因为虚拟机的启动、安装、部署代价非常高,持续时间周期很长。在OpenStack上做开发,如果要跑一两个小时才能出结果,这在传统企业是根本无法接受的。采用容器的CI以后,这种局面得到彻底改观。所有的提交以及镜像发布到测试,可以做到分钟级解决。借助各种内网的源,整个镜像和发布过程很快。

11.png



对于新的PaaS平台来说,重点工作之一是通过发布管理去发布。PaaS平台偏运维,在招银云创内部,运维人员能够深切地感受到对自身带来的巨大帮助,以前纯手工的过程全部自动化完成。在过去的两个月,招银云创内部推动PaaS平台积极性最高的也是运维人员,实现了从手工到完全自动化,甚至智能化。招银云创已经做到代码一提交,马上去做镜像,然后推送到发布的一体化流程,这在以往不可想象。在没有容器之前,哪怕采用Spring Cloud开发应用,也无法发挥它的特点。

12.png



回到镜像管理,镜像管理能够看到很多方案,但对企业来说,镜像积累到一定程度,变成企业的资产,日后有可能代替电子仓库。云创镜像积累的很好,一些不同版本都能够得到快速满足,实现快速迭代,满足开发需求。

13.png



经过两个月PaaS平台的使用,运维人员感触最深的是“开发人员已经看不到IaaS平台了”。为什么这么说?以前开发人员经常要在IaaS平台里面启动各种虚拟机,来进行测试、完善。用了PaaS平台后,开发、发布、交付生产线,都已经不需要关注底层是虚拟机还是物理机,只需要关注一个PaaS平台。

14.png