Jhipster 项目之架构分析之gradle目录结构

jhipster是一个快速生成项目的脚手架,能够快速提高开发效率,本身并不是一个开发技术,但是这个东西本身实际上是一个最佳实践,我们可以看看他的最佳实践做一些学习。 项目目录结构 项目的目录结构如上图所示,接下来,咱们详细的讲解一下目录结构的作用。 其中.gradle,.idea,node_modules,out,build这几个文件是工具自动生成文件,咱们不需要了解,就不细说这个了, .jhipster目录 这个目录中都是定义的实体配置,还有就是jhi提供的钩子,可以在开发插件时利用这些钩子做一些有意思的事情,比如给实体添加实体审核的,这里面的文件大部分情况下我们是不需要动地,因为这些文件是jhipster自动帮忙生成的。 { "name": "About", "fields": [ { "fieldName": "info", "fieldType": "String" }, { "fieldName": "content", "fieldType": "String" }, { "fieldName": "order", "fieldType": "Long" } ], "relationships": [], "changelogDate": "20190105111036", "entityTableName": "about", "dto": "no", "pagination": "no", "service": "no", "jpaMetamodelFiltering": false, "fluentMethods": true, "clientRootFolder": "", "applications": "*", "enableEntityAudit": true } 这里面有关系设置,记录liqubase数据库中的变更日期集,实体表明,是否用dto,是否用分页,是否用service,是否开启jpa元数据模型过滤,客户端 根目录,是否启用实体审核等信息。 [ { "name": "Entity Audit generator", "npmPackageName": "generator-jhipster-entity-audit", "description": "Add support for entity audit and audit log page", "hookFor": "entity", "hookType": "post", "generatorCallback": "jhipster-entity-audit:entity" } ] 插件类型,执行时间,执行回调 [Read More]

Jhipster 项目之架构分析之huskrc

在开发的时候,我们有的时候需要在提交的时候做一些校验,比如控制一些不规范的提交,不规范的推送,这里刚好又这么个校验工具huskrc 这个工具现在也是有很多有名的开源软件在使用,比如

jQuery
babel
create-react-app
Next.js
Hyper
Kibana
JSON Server
Hotel

Jhipster同样采用了,这个工具来做前端的一些lint校验,具体配置如下所示

{
  "hooks": {
     "pre-commit": "lint-staged"
  }
}

钩子的内容,在提交前执行lint-staged,好的本篇文章就降到这里,具体的huskrc可以看我的关于huskrc详细介绍的博文

Jhipster 项目之架构分析之packge.json

由于前端的项目现在发展的日新月异,同样有类似后台的依赖管理工具,前端的依赖管理工具就是NPM(Node Package Manager), { "name": "demo", "version": "0.0.0", "description": "Description for demo", "private": true, "license": "UNLICENSED", "cacheDirectories": [ "node_modules" ], "dependencies": { "@angular/common": "7.1.0", "@angular/compiler": "7.1.0", "@angular/core": "7.1.0", "@angular/forms": "7.1.0", "@angular/platform-browser": "7.1.0", "@angular/platform-browser-dynamic": "7.1.0", "@angular/router": "7.1.0", "@fortawesome/angular-fontawesome": "0.3.0", "@fortawesome/fontawesome-svg-core": "1.2.8", "@fortawesome/free-solid-svg-icons": "5.5.0", "@ng-bootstrap/ng-bootstrap": "4.0.0", "bootstrap": "4.1.3", "core-js": "2.5.7", "moment": "2.22.2", "ng-jhipster": "0.5.6", "ngx-cookie": "2.0.1", "ngx-infinite-scroll": "6.0.1", "ngx-webstorage": "2.0.1", "rxjs": "6.3.3", "swagger-ui": "2.2.10", "tslib": "1.9.3", "zone.js": "0.8.26", "ng-diff-match-patch": "2.0.6" }, "devDependencies": { "@angular/cli": "7. [Read More]

Jhipster 项目之架构分析之perttier

在开发代码时候,前端项目如何让代码格式固定,有很多办法,批量格式化代码的神器,虽然咱们前面已经有editorconfig来保证跨开发工具的缩进啊,之类的包支持一直,但是如果需要批量格式化代码,该如何处理呢,刚好 perttier就是这个神器,可以陪和前面的huskrc在提交前,批量把之前的代码统一按配置的格式化处理

.prettierrc

# Prettier configuration

# 每行行宽
printWidth: 140
# 单引号
singleQuote: true
# tab是4个空格代替
tabWidth: 4
# 不用tab字符
useTabs: false

# js and ts rules:
arrowParens: avoid

# jsx and tsx rules:
jsxBracketSameLine: false

通过上面的配置,就可以在前端代码中作出如下的格式化。

.prettierignore

针对这种批量格式化任务呢,我们针对一些不必要的文件不用格式化,比如node_modules,这个是别人开发好的库文件,格式化了,没什么用,还有编译后的文件,这个不是我们源码需要处理的内容,再有就是锁定版本的文件,更是不需要更新了

node_modules
target
package-lock.json

那么通过上面两个文件,我们就可以处理批量格式化了,本篇文章到此结束

Jhipster 项目之架构分析之yo-rc.json

jhipster generator这个工具本身使用yeoman开发的,那么yo他的开发工具生成代码,jhipster利用这个配置文件来保存生成项目时的一些配置,比如项目名称,用的什么组件之类的

{
    "generator-jhipster": {
        "applicationType": "monolith",
        "gitCompany": "",
        "baseName": "demo",
        "packageName": "org.ylf.demo",
        "packageFolder": "org/ylf/demo",
        "serverPort": 8080,
        "serviceDiscoveryType": false,
        "authenticationType": "jwt",
        "uaaBaseName": "../uaa",
        "cacheProvider": "ehcache",
        "enableHibernateCache": true,
        "websocket": false,
        "databaseType": "sql",
        "devDatabaseType": "h2Disk",
        "prodDatabaseType": "mysql",
        "searchEngine": false,
        "enableSwaggerCodegen": false,
        "messageBroker": false,
        "buildTool": "gradle",
        "useSass": false,
        "clientPackageManager": "npm",
        "testFrameworks": ["gatling", "cucumber", "protractor"],
        "enableTranslation": true,
        "nativeLanguage": "zh-cn",
        "languages": ["en", "zh-cn"],
        "clientFramework": "angularX",
        "jhiPrefix": "jhi",
        "jhipsterVersion": "5.7.1",
        "jwtSecretKey": "ZDY5Y2JlZjdlNTNjYTU2MTA3NzcyZjZmMTA2MDVhZWJiMjQ4YjQ2ZTQ2ODIzMzUxZjgzZTlhNzZhOTU4MjljZDBlNjY3OGY5NTBlODgyZGFhYzBlZDc5Y2YwNzFmZDMyMTA4OTdlYTRlNmU4MGZhN2RmZmZhYTI5YjkzZjViYjI=",
        "otherModules": []
    },
    "git-provider": "GitLab",
    "git-company": "flydragon",
    "repository-name": "demo",
    "generator-jhipster-entity-audit": {
        "auditFramework": "custom"
    }
}

内容本身并不复杂,我们知道怎么回事,知道这个文件使用来做什么的就好了,这篇文章到此结束

Cilium 1.4发布了

Cilium 1.4:多集群服务路由,DNS授权,IPVLAN支持,透明加密,Flannel集成,与其他CNI的基准测试,…… 通告 我们很高兴地宣布Cilium 1.4版本。 该版本引入了几项新功能以及优化和可扩展性工作。 重点包括增加全局服务,提供跨多个集群的Kubernetes服务路由、DNS请求/响应感知授权和可见性、透明加密(beta)、IPVLAN支持以获得更好的性能和延迟(beta)、与Flannel集成、GKE在COS上支持、基于AWS元数据的策略实施(alpha)以及优化内存和CPU使用的重要工作。 像往常一样,感谢过去4个月中在版本1.3和1.4之间贡献了1048次提交的Cilium开发人员及整个社区。 Cilium是什么? Cilium是一个开源软件,用于透明地提供和保护使用Kubernetes、Docker和Mesos等Linux容器管理平台部署的应用程序服务之间的网络和API连接。 Cilium的基础是一种名为BPF的新Linux内核技术,它可以在Linux本身内动态插入强大的安全性、可见性和网络控制逻辑。BPF用于提供诸如多集群路由,负载均衡以取代kube-proxy,使用X.509证书的透明加密以及网络和服务安全性等功能。除了提供传统的网络级安全性之外,BPF的灵活性还可以通过应用程序协议和DNS请求/响应的上下文实现安全性。Cilium与Envoy紧密集成,并提供基于Go的扩展框架。由于BPF在Linux内核中运行,因此可以应用所有Cilium功能,而无需对应用程序代码或容器配置进行任何更改。 有关 Cilium 的更详细的介绍, 请参阅Cilium简介 一节。 多集群服务路由 Cilium 1.3在多个集群之间引入了基本的pod IP路由功能。Cilium 1.4引入了基于标准Kubernetes服务的全局服务概念。全局服务允许用户指定Kubernetes服务在多个集群中可用。然后,该服务可以在多个集群中具有后端pod。 用户体验就像在每个集群中定义具有相同名称和命名空间的Kubernetes服务并添加注释以将其标记为全局一样简单。 当pod向上或向下扩展或变得不健康时,Kubernetes运行状态检查信息可用于自动添加和删除后端服务。 控制平面建立在etcd之上,类似于Kubernetes原生的操作方式,具有弹性和简单性作为其基本设计模式。每个集群继续运行其自己的etcd集群,并且复制以只读方式进行,这可确保集群中的故障不会影响其他集群。 将集群连接在一起就像使用云供应商的标准路由API或基于常规IP地址的VPN网关和隧道的本地基础设施在VPC之间提供路由,然后通过内部Kubernetes负载均衡器暴露Cilium控制平面以将其暴露给内部VPC一样简单。TLS用于使用作为Kubernetes Secret管理的证书和密钥对客户端和服务器进行身份验证。 IPVLAN支持(测试版) 添加了一种新的基于IPVLAN的数据路径模式。与基于veth的体系结构相比,IPVLAN具有低延迟优势。使用netperf在3.40Ghz Xeon上的两个本地容器之间测量了以下基准测试,并使用单核禁用超线程。与veth相比,IPVLAN的P99延迟相对较低(越低越好): IPVLAN和veth之间的最大吞吐量(越高越好)非常相似,但是通过从内核编译netfilter/iptables可以实现非常显着的性能提升。如果您不使用NodePort服务并且在离开Kubernete worker node时不需要伪装网络流量,则已经可以完全运行您的Kubernetes集群。我们将在接下来的几周内提供有关如何运行iptables和kube-proxy的指南。 IPVLAN是1.4中的beta级功能,有关如何启用和配置该功能的说明,请参阅 IPVLAN入门指南 。 DNS请求/响应的安全性和可见性 Cilium 1.4扩展了现有的DNS安全策略模型,以了解各个pod发出的DNS请求以及它们收到的DNS响应。 这显着提高了访问集群外部服务的pod的安全性: 在执行DNS查找时,可以将Pod限制为具有最小权限,即 pod可以仅限于查找匹配模式的DNS名称,例如 *.domain.com 。 任何超出允许模式的请求都将收到 request refused DNS响应。 DNS查找后的通信可以限制为特定pod接收的DNS响应中返回的IP地址。 这显着降低了受损应用程序的权限,并提高了基于DNS的策略规则的可靠性,因为执行逻辑不再需要知道DNS名称可以映射到的所有可能的IP地址。 特别是对于云供应商提供的流行存储,消息传递和数据库服务,单个DNS名称可以映射到数百或数千个IP地址。 现在可以通过API访问的Cilium授权日志记录层记录DNS查找和响应。 这提供了pod执行的每个DNS请求和响应的精确日志。 上面的示例显示了一个成功的DNS序列,然后是DNS服务器响应的对IP的HTTP请求。 这是应用程序的行为方式和允许的方式。 后续HTTP请求可以使用缓存的DNS信息,允许此类请求。 DNS信息将根据记录中的TTL信息超时。 右侧是应用程序在允许的DNS策略之外执行DNS查找的序列。 它还显示,如果应用程序无法执行DNS查找,则在应用程序无法在以下位置查找DNS名称时,即使IP地址实际映射到允许的DNS名称,也会阻止任何尝试联系IP地址的尝试。一点。 策略示例 apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "egress-domain-wildcard" spec: endpointSelector: matchLabels: app: myService egress: - toEndpoints: - matchLabels: 'k8s:io. [Read More]

使用Istio打造微服务(第1部分)

Istio 是一个由Google,IBM和Lyft团队合作开发的开源项目,它提供了基于微服务的应用程序复杂性的解决方案,仅举几例: 流量管理 :超时,重试,负载均衡, 安全性: 最终用户身份验证和授权, 可观察性: 跟踪,监控和记录。 所有这些都可以在应用程序层中解决,但是您的服务不再是“微型”,相对于提供业务价值的资源,实现这些的所有额外工作都是公司资源的压力。我们来举个例子: PM:添加反馈功能需要多长时间? 开发:两个冲刺(敏捷开发中的术语,一般一个冲刺周期30天)。 PM:什么……? 那只是一个CRUD! 开发:创建CRUD很容易,但我们需要对用户和服务进行身份验证和授权。而且由于网络不可靠,我们需要在客户端实施重试和熔断器,并确保我们不会占用整个系统,我们需要Timeout和Bulkheads,另外还要检测我们需要监控的问题,跟踪[… ] PM:那么我们就把它放在产品服务中吧。哎呀! 你明白了,必须满足所有形式才可以为我们添加一项巨大的服务(有很多不是业务功能的代码)。在本文中,我们将展示Istio如何从我们的服务中删除所有上述交叉问题。 注意: 本文假设您具有Kubernetes的知识。如果不是这种情况,我建议您阅读 我对Kubernetes的介绍,然后继续阅读本文。 关于Istio 在没有Istio的世界中,一个服务向另一个服务直接发出请求,并且在发生故障的情况下,服务需要通过重试,超时,打开熔断器等来处理它。 为了解决这个问题,Istio通过与服务完全分离,并通过拦截所有网络通信来提供一种巧妙的解决方案。这样做可以实现: Fault Tolerance - 使用响应状态代码,它可以在请求失败并重试时理解。 Canary Rollouts - 仅将指定百分比的请求转发到新版本的服务。 监控和指标 - 服务响应所花费的时间。 跟踪和可观察性 - 它在每个请求中添加特殊header,并在集群中跟踪它们。 安全性 - 提取JWT令牌并对用户进行身份验证和授权。 仅举几例(仅举几例),让您感兴趣! 我们来看一些技术细节吧! Istio的架构 Istio拦截所有网络流量,并通过在每个pod中注入智能代理作为sidecar来应用一组规则。启用所有功能的代理包括 数据平面, 并且这些代理可由控制平面 动态配置。 数据平面 注入的代理使Istio能够轻松满足我们的要求。举个例子,我们来看看重试和熔断器功能。 总结一下: Envoy将请求发送到服务B的第一个实例,但它失败了。 Envoy sidecar重试。(1) 返回对调用代理的失败请求。 这将打开熔断器并在后续请求中调用下一个服务。(2) 这意味着您不必使用另一个重试库,您不必在编程语言X,Y或Z中开发自己的Circuit Breaking和Service Discovery实现。所有这些都是开箱即用的。这些功能都是通过Istio来实现,你不需要更改代码。 很好! 现在你想加入Istio的航行,但你仍然有一些疑虑,一些悬而未决的问题。这是一个一刀切的方案,你对它持怀疑态度,因为它总是最终成为一刀切的无解方案! 你最终低声说了这个问题:“这是可配置的吗?” [Read More]

无服务器与容器

无服务器与容器 原文链接:https://dzone.com/articles/serverless-vs-containers 作者:Yan Cui 译者:殷龙飞 让我们来看看采用率,工具支持以及围绕无服务器和容器化争论的其他因素。 在无服务器和容器中,我们有两种令人惊叹的技术,可以为工程师提供高效的,与机器无关的抽象。然而,两个阵营之间似乎存在着不可逾越的鸿沟。 如果你读过我在过去两年写的任何内容,你就会知道我坚定地站在无服务器阵营。但我也是容器的早期采用者。在Docker达到1.0里程碑后不久,2015年初我的第一个容器化项目问世。 这篇文章不是企图另一次引发阵营战争或宣布某个阵营的胜利。相反,我将尝试客观地看待无服务器和容器的状态,根据它们提供的利弊权衡,并对未来的情况给出诚实的看法。 鉴于无服务器和FaaS函数即服务(FAAS)通常已经可以互换使用,为了本文的目的,我将限制无服务器的定义为FAAS产品,例如AWS Lambda。 容器状态 自从Docker早期可用以来,事情已经走过了漫长的道路。随着我们在容器上运行的系统越来越复杂,我们的需求已经催生了丰富的工具生态系统。 AWS还拥有自己的托管容器服务ECS。这提供了与AWS生态系统其他部分更紧密的集成。 如服务网格也正在获得可见性和被采用。它们将常见的交叉问题(例如跟踪和断路器)移出应用层。通过解决基础架构层中的这些问题,它们为这些挑战提供了语言和运行时无关的解决方案。这使它们非常适合现代IT组织,即使用各种不同语言的构建微服务。 无服务器状态 虽然围绕无服务器的炒作并没有和容器一样长。值得记住的是,在Lamber达到1.0之后仅一个月,AWS Lambda就在 2014年发布了。它随附了CloudWatch的基本日志记录和监视支持,即使我们现在依赖的许多事件源(例如API Gateway)都是在之后引入的。 除了这些托管服务之外,还有一些解决方案可以让您在自己的Kubernetes集群上运行无服务器。这些包括谷歌和合作公司最近宣布的。虽然这些解决方案试图满足许多开发人员的需求,但我感到他们放弃了无服务器的最佳功能 - 不必担心服务器! 采用趋势 根据一些调查和研究,无服务器和容器的采用正在快速增长。以下是我认为的一些亮点。 A Cloudability发现,2017年第四季度AWS用户的容器采用量增长了246%,高于第三季度的206%。同时,同一项研究发现,2017年第四季度AWS用户无服务器采用量增长了667%,高于第三季度的321%。 无服务器公司最近发现,2018年有82%的联络员使用无服务器,高于2017年的45%。超过53.2%的人表示他们使用无服务器技术对他们的工作至关重要。 无服务器公司的调查还报告说,在采用无服务器之前,24%的联络员对公共云的使用经验有限或为零。20.2%的为拥有1000多名员工的大型企业工作。 Logz.io的 DevOps Pulse 调查发现,在2018年,60.71%的联络员采用了容器编排,高于2017年的42.11%。 有趣的是,DevOps Pulse调查显示,无服务器采用率比其他报告小得多。从2018年的30。55%(2017年)上升到42.58%。这可能与其联络员的分布有关。其中28.54%认为自己是开发者,而44.26%认定为DevOps,DevSecOps,SysAdmin或SRE。 这与我在容器和无服务器阵营之间的上述鸿沟的经验一致。那些认为自己是开发人员的人更倾向于无服务器,而那些被认为是DevOps的人更有可能选择容器。 控制与责任 关于无服务器与容器的争论通常始于控制,或者在无服务器的情况下缺乏控制。这不是新的。事实上,我清楚地记得当AWS在2009年开始获得牵引力时围绕控制的相同辩论。现在10年后,尘埃落定于原始辩论,但我们未能吸取教训。 想要控制是人的本性,但你愿意为此付出多少钱? 您知道您将承担的总体拥有成本(TCO)吗? 控制自己的基础设施的能力带来了很多责任。要承担这些责任,您需要拥有组织中的相关技能。这意味着工资(很容易成为大多数组织的最大开支),代理费以及从工程师和经理那里抽出时间进行招聘和入职。 考虑到所涉及的TCO,具有该控制的目标必须是针对某些事物进行优化(例如,为业务关键工作流程实现可预测的性能),并且不为其自身控制。 构建基于容器的通用计算平台需要大量的工程专业知识和投资,该平台与AWS Lambda等无服务器产品一样高效,可扩展且具有弹性。大多数组织根本没有能力解决这个问题。尽管有大量的时间和金钱投入,但我知道一些大企业在他们的尝试中惨遭失败。 工具支持 使用无服务器,您可以从box-logging,指标和跟踪中获得基本的可观察性工具。尽管有这些警告,但一开始它们通常就足够了。 传统上迎合IAAS或容器市场的供应商也开始为无服务器应用程序提供支持。但是,他们需要调整自己的方法,因为无服务器无法再使用基于代理的方法。 还有越来越多的供应商专注于解决无服务器应用程序的可观察性和安全性问题。但是,大多数仍处于开发的早期阶段,尚未准备好进行严肃的生产使用。 与无服务器相比,容器空间具有更成熟和多样化的工具生态系统。事实上,我发现使用容器的挑战之一是处理绝大多数的选择! 有充足的修补机会,我也发现团队可能会忽略奖品(即为我们的客户建立更好的产品),并陷入过度工程的陷阱。 无服务器的工具支持将会越来越好,但至少目前,仍然远远落后于容器。在容器领域工作的人面临的挑战是抵制修补和追求简单的冲动。 供应商锁定:风险与奖励 无服务器的批评者通常使用供应商锁定作为他们的论据。与此同时,大多数AWS客户实际上都在要求更紧密的集成,以便他们可以从平台中获取更多价值。 可以肯定的是,供应商锁定是一种风险。但正如任何投资者都会告诉你的那样,如果你不承担风险,你就永远不会赚钱。诀窍是采取能够带来最佳回报的计算风险。 对于它所获得的所有关注,供应商锁定对于少数人来说是一种危险。相反,您更有可能找到过度设计的解决方案来阻止供应商锁定,而不是创建其他形式的锁定,无论是内部团队还是其他私有云供应商。 同样,这不是新的。几年前我们与ORM进行了同样的辩论。我们创建了所有这些抽象来防止供应商锁定,除了风险从未实现为我们大多数人的问题。所发生的一切都是我们花费了大量精力和时间,并推迟了我们的产品上市时间,因为这些产品从未成为问题。 更糟糕的是,ORM引入了他们自己的问题和复杂性,并持续阻碍了发展。它成为开发团队的一项税收,并在可预见的未来减缓了功能交付。 对于那些必须进行数据库迁移的人来说,ORM并没有让事情变得更好。除了其他一切之外,这只是你必须处理的另一个问题。 看到历史重演,这次,甚至更高的层次可能会影响整个组织,这是痛苦的! 公司发现无服务器团队的工作量越来越多,工程师也越来越多。所以,就像一个明智的投资者一样,我们应该问的问题是:“重要的生产力回报是否值得锁定风险,实现问题的可能性很小?” 未来是无服务器还是容器? 无服务器为您提供了大量的生产力提升,但却以控制基础架构为代价。 对于我们的许多工作流程 - 网络API,流处理,cron作业等 - 实际上我们不需要这些所有的控制,我们应该祝福为我们处理管道的人。 [Read More]

后 Kubernetes 时代的微服务

原文链接:https://www.infoq.com/articles/microservices-post-kubernetes 作者:Bilgin Ibryam 英文审校:Daniel Bryant 译者:殷龙飞 关键要点 微服务架构仍然是分布式系统最流行的架构风格。 但 Kubernetes 和云原生运动已经大规模重新定义了应用程序设计和开发。 在云原生平台上,服务的可观察性是不够的。 更基本的先决条件是通过实施健康检查,对信号做出反应,声明资源消耗等,使微服务自动化。 在后 Kubernetes 时代,服务网格技术将完全取代使用库来实现操作网络问题(例如 Hystrix 断路器)。 微服务现在必须通过从多个维度实现幂等性来设计用于“恢复”。 现代开发人员必须精通编程语言以实现业务功能,并且同样精通云原生技术以满足非功能性基础架构级别要求。 微服务炒作开始于一堆关于组织结构,团队规模,服务规模,重写和抛出服务而不是修复,避免单元测试等的极端想法。根据我的经验,大多数这些想法被证明是错误的,而不是实用的,或者至少一般不适用。 如今,大多数剩余的原则和实践都是如此通用和松散地定义,以至于它们在未来许多年都会成立,而在实践中却没有多大意义。 在 Kubernetes 诞生之前几年被采用,微服务仍然是分布式系统最流行的架构风格。 但 Kubernetes 和云原生运动已经大规模重新定义了应用程序设计和开发的某些方面。 在本文中,我想质疑一些原始的微服务理念,并承认它们在后 Kubernetes 时代并不像以前那样强大。 不仅可观察,而且还有自动化服务 可观察性从一开始就是微服务的基本原则。 虽然对于一般的分布式系统来说它是正确的,但今天(特别是在 Kubernetes 上),它的很大一部分是平台级别的开箱即用(例如进程运行状况检查,CPU 和内存消耗)。 最低要求是应用程序以 JSON 格式登录控制台。 从那时起,平台可以跟踪资源消耗,请求跟踪,收集所有类型的指标,错误率等,而无需太多的服务级别开发工作。 在云原生平台上,可观察性是不够的。 更基本的先决条件是通过实施健康检查,对信号做出反应,声明资源消耗等使微服务自动化 。可以将几乎任何应用程序放入容器中并运行它。 但是要创建一个容器化的应用程序,可以通过云原生平台自动化和协调编排,需要遵循一定的规则。 遵循这些 原则和模式 ,将确保生成的容器在大多数容器编排引擎中表现得像一个优秀的云本地公民,允许以自动方式对它们进行调度,扩展和监视。 我们希望平台不必观察服务中发生的情况,而是希望平台检测异常情况并按照声明进行协调。 无论是通过停止将流量引导到服务实例,重新启动,向上和向下扩展,还是将服务移动到另一个健康的主机,重试失败的请求或其他,这都无关紧要。 如果服务是自动化的,则所有纠正措施都会自动发生,我们只需要描述所需的状态,而不是观察和反应。 服务应该是可观察的,但也可以在没有人为干预的情况下通过平台进行整改。 智能平台和智能服务,但有正确的责任 在从 SOA 转向微服务世界的过程中, “智能端点和哑管”的概念是服务交互的另一个根本转变。 在微服务领域,服务不依赖于集中式智能路由层的存在,而是依赖于拥有某些平台级功能的智能端点。 这是通过在每个微服务中嵌入传统 ESB 的一些功能并转换到没有业务逻辑元素的轻量级协议来实现的。 虽然这仍然是在不可靠的网络层(使用 Hystrix 等库 ) 实现服务交互的流行方式 ,但现在,在后 Kubernetes 时代,它已经完全被服务网格技术所取代 。 有趣的是,服务网格甚至比传统的 ESB 更智能。 网格可以执行动态路由、服务发现、基于延迟的负载平衡、响应类型、指标和分布式跟踪、重试、超时,你能想到的这里都有。 [Read More]

使用 Kubernetes 和 Istio 进行基于容器的全面服务监控

原文链接:https://www.infoq.com/articles/envoy-service-mesh-cascading-failure 作者:Jose Nino 作者:Daniel Hochman 译者:殷龙飞 关键要点 在过去的四年中,Lyft 已从单体架构转变为数百个微服务。随着微服务数量的增加,由于级联故障或意外内部拒绝服务导致的中断次数也在增加。 今天,这些故障情况在 Lyft 基础设施中基本上是一个已解决的问题。Lyft 部署的每项服务都通过使用 Envoy 代理自动获得吞吐量和并发保护。 Envoy 可以作为中间件部署或仅在请求入口时部署,但最大的好处来自于在应用程序本地的入口和出口部署它。在请求的两端部署 Envoy 允许它充当服务器的智能客户端和反向代理。 在接下来的几个月里,Lyft 将与 Netflix 的并发限制库背后的团队合作,将基于其库的系统带入 Envoy L7 过滤器。 级联故障是高吞吐量分布式系统中不可用的主要原因之一。在过去的四年中,Lyft 已从单体架构转变为数百种微服务。随着微服务数量的增加, 由于级联故障或意外内部拒绝服务导致的中断次数也在增加。今天,这些故障情况在 Lyft 基础设施中基本上是一个已解决的问题。 Lyft 部署的每项服务都会自动获得吞吐量和并发保护。通过对我们最关键的服务进行一些有针对性的配置更改,基于负载的事件减少了 95%,从而影响了用户体验。 在我们检查特定的故障情况和相应的保护机制之前,让我们首先了解如何在 Lyft 部署网络防御。Envoy 是一个 源自 Lyft 的代理, 后来开源并捐赠给 Cloud Native Computing Foundation 。Envoy 与许多其他负载均衡解决方案的区别在于它被设计为以“网格”配置部署。 Envoy 可以作为中间件部署或仅在请求入口时部署,但最大的好处来自于在应用程序本地的入口和出口部署它。在请求的两端部署 Envoy 允许它充当服务器的智能客户端和反向代理。 在双方,我们可以选择采用速率限制和断路来保护服务器免受各种情况下的过载。 核心概念 并发和速率限制 并发和速率限制是相关的,但不同的概念; 同一枚硬币的两面。在考虑限制系统负载时,运营商传统上会考虑每秒的请求数。 限制发送到系统的请求的速率的行为是速率限制的。通常进行压力测试以确定服务将变为过载的请求率,然后将限制设置在低于该点的某处。 在某些情况下,业务逻辑决定了速率限制。 在硬币的另一面,我们有并发性,即同时使用多少个单元。这些单位可以是请求,连接等。例如,我们可以考虑某个时间点的并发飞行请求数,而不是考虑请求率。 当我们考虑并发请求时,我们可以应用排队理论来确定服务在队列开始构建之前可以处理的并发请求数,请求延迟增加,以及服务因资源耗尽而失败。 全局与本地决策 Envoy 中的断路器是根据本机信息计算的。每个 Envoy 实例都会跟踪自己的统计数据并制定自己的断路决策。与全局系统相比,该模型具有一些优势。 第一个是可以在内存中计算限制,而无需对中央系统进行网络调用。第二个是限制随着集群的大小而扩展。第三,限制考虑了机器之间的差异, 无论它们是否收到不同的查询组合,或者在性能上有差异。 [Read More]