上一章讲了gradlew的类unix的脚本，这章主要讲一下window的内容 @if "%DEBUG%" == "" @echo off @rem ########################################################################## @rem @rem Gradle startup script for Windows @rem @rem ########################################################################## @rem Set local scope for the variables with windows NT shell if "%OS%"=="Windows_NT" setlocal set DIRNAME=%~dp0 if "%DIRNAME%" == "" set DIRNAME=. set APP_BASE_NAME=%~n0 set APP_HOME=%DIRNAME% @rem Add default JVM options here. You can also use JAVA_OPTS and GRADLE_OPTS to pass JVM options to this script. set DEFAULT_JVM_OPTS= @rem Find java.exe if defined JAVA_HOME goto findJavaFromJavaHome set JAVA_EXE=java. [Read More]

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]

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

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

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

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

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

由于前端的项目现在发展的日新月异，同样有类似后台的依赖管理工具，前端的依赖管理工具就是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]

在开发代码时候，前端项目如何让代码格式固定，有很多办法，批量格式化代码的神器，虽然咱们前面已经有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 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：多集群服务路由，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 是一个由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]

原文链接：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]