├── 2018 ├── 10 │ ├── does-the-service-mesh-spell-the-end-for-middleware │ │ └── index.md │ ├── how-to-map-cloud-native-workloads-to-kubernetes-controllers │ │ └── index.md │ ├── manipulating-istio-and-other-custom-kubernetes-resources-in-golang │ │ └── index.md │ ├── myth-cloud-native-portability │ │ └── index.md │ ├── practice-for-coohom-using-istio-in-production │ │ └── index.md │ ├── raw-tcp-traffic-shaping-with-istio-1-1-0 │ │ └── index.md │ ├── set-sail-a-production-ready-istio-adapter │ │ └── index.md │ ├── the-future-of-service-mesh-part-ones-ervice-mesh-architectures-inevitable │ │ └── index.md │ └── the-future-of-service-mesh │ │ └── index.md ├── 11 │ ├── cilium-13-go-extensions-for-envoy-cassandra-memcached-support │ │ └── index.md │ ├── design-patterns-for-microservice-communication │ │ └── index.md │ ├── envoy-grpc-and-rate-limiting │ │ └── index.md │ ├── evaluation-of-serverless-frameworks-for-kbe │ │ └── index.md │ ├── istio-envoy-grpc-metrics-winning-with-service-mesh-in-practice │ │ └── index.md │ ├── istio-is-it-a-bird-microgateway-blog-series-part-4 │ │ └── index.md │ ├── istio-routing-basics │ │ └── index.md │ ├── istio-what-happens-when-control-plane-is-down │ │ └── index.md │ ├── microservices-monitoring-with-envoy-service-mesh-prometheus-grafana │ │ └── index.md │ ├── service-mesh-meet-event-mesh │ │ └── index.md │ ├── service-mesh-with-envoy-101 │ │ └── index.md │ ├── sre-resiliency-bolt-on-sidecar-rate-limiting-with-envoy-sidecar │ │ └── index.md │ ├── transcoding-grpc-to-http-json-using-envoy │ │ └── index.md │ └── why-is-service-mesh │ │ └── index.md ├── 12 │ ├── distributed-tracing-with-envoy-service-mesh-jaeger │ │ └── index.md │ ├── from-fragmented-microservices-ecosystem-to-service-mesh │ │ └── index.md │ ├── seamless-cloud-native-apps-with-grpc-web-and-istio │ │ └── index.md │ └── serverless-jenkins-with-jenkins-x │ │ └── index.md ├── 05 │ ├── gitops-for-istio-manage-istio-config-like-code │ │ └── index.md │ ├── microservices-docker-kubernetes-serverless-service │ │ └── index.md │ └── the-path-to-service-mesh │ │ └── index.md ├── 06 │ ├── 8-ways-a-service-mesh-eases-microservices-deployment │ │ └── index.md │ ├── Istio-is-not-just-for-microservices-secure-your-kubernetes-services-using-istio-service-mesh │ │ └── index.md │ ├── building-istio-with-minikube-in-a-container-and-jenkins │ │ └── index.md │ ├── comprehensive-container-based-service-monitoring-with-kubernetes-and-istio │ │ └── index.md │ ├── containers-service-mesh-and-api-gateways-it-starts-at-the-edge │ │ └── index.md │ ├── implementing-a-java-rate-limiting-service-for-the-ambassador-api-gateway-part-3 │ │ └── index.md │ ├── introducing-the-istio-v1alpha3-routing-api │ │ └── index.md │ ├── istio-envoy-cert-manager-lets-encrypt-for-tls │ │ └── index.md │ ├── making-most-out-microservices-service-mesh │ │ └── index.md │ ├── manage-microservices-traffic-using-istio │ │ └── index.md │ ├── part-2-rate-limiting-for-api-gateway-daniel-bryant │ │ └── index.md │ ├── rate-limiting-a-useful-tool-with-distributed-systems-part1 │ │ └── index.md │ ├── service-mesh-and-cookpad │ │ └── index.md │ ├── the-rise-of-the-istio-service-mesh │ │ └── index.md │ ├── the-universal-data-plane-api │ │ └── index.md │ ├── tracing-grpc-with-istio │ │ └── index.md │ ├── traffic-routing-between-fn-functions-using-fn-project-and-istio-fd │ │ └── index.md │ ├── twistlock-makes-istios-security-layer-more-robust-easier-to-monitor │ │ └── index.md │ ├── using-linkerd-as-a-service-mesh-proxy-at-wepay │ │ └── index.md │ ├── vistio-visualize-your-istio-mesh-using-netflixs-vizceral │ │ └── index.md │ └── vp-microservices-communication-governance-using-service-mesh │ │ └── index.md ├── 07 │ ├── ab-testing-on-kubernetes-with-istio-0-8 │ │ └── index.md │ ├── designing-a-rate-limiting-service-for-ambassador-part-4 │ │ └── index.md │ ├── distributed-tracing-istio-and-your-applications │ │ └── index.md │ ├── how-service-mesh-addresses-3-major-microservices │ │ └── index.md │ ├── k8-istio-little-deep-dive │ │ └── index.md │ ├── service-mesh-architecture-radicalizes-container-networking │ │ └── index.md │ ├── service-mesh-architectures │ │ └── index.md │ ├── sidecar-design-pattern-in-your-microservices-ecosystem │ │ └── index.md │ └── the-circonus-istio-mixer-adapter │ │ └── index.md ├── 08 │ ├── application-safety-and-correctness-cannot-be-offloaded-to-istio-or-any-service-mesh │ │ └── index.md │ ├── cilium1-2-dns-security-policies-eks-support-clustermesh-kube-router-integration │ │ └── index.md │ ├── enabling-the-financial-services-shift-to-microservices │ │ └── index.md │ ├── envoy-service-mesh-cascading-failure │ │ └── index.md │ ├── google-istio-bigger-kubernetes-serverless │ │ └── index.md │ ├── hands-on-canary-deployments-with-istio-and-kubernetes │ │ └── index.md │ ├── hashicorp-extends-consul-to-support-other-service-meshes │ │ └── index.md │ ├── how-cilium-enhances-istio-with-socket-aware-bpf-programs │ │ └── index.md │ ├── istio-aims-to-be-the-mesh-plumbing-for-containerized-microservices │ │ └── index.md │ ├── istio-service-mesh-tech-boosts-kubernetes-work-with-trade-offs │ │ └── index.md │ ├── securing-ingress-services-in-istio-with-lets-encrypt-on-kubernetes │ │ └── index.md │ ├── tracing-services-with-istio │ │ └── index.md │ └── why-you-should-care-about-istio-gateways │ │ └── index.md └── 09 │ ├── api-management-and-service-mesh │ └── index.md │ ├── envoy-stats │ └── index.md │ ├── going-beyond-container-orchestration │ └── index.md │ ├── hands-on-canary-deployments-with-istio-and-kubernetes2 │ └── index.md │ ├── increasing-security-with-a-service-mesh-christian-posta-explores-the-capabilities-of-istio │ └── index.md │ ├── istio-service-mesh-interview-harrington │ └── index.md │ ├── microservice-observability-with-istio │ └── index.md │ ├── microservices-post-kubernetes │ └── index.md │ ├── nginx-ingress-vs-kong-vs-traefik-vs-haproxy-vs-voyager-vs-contour-vs-ambassador │ └── index.md │ ├── serverless-vs-containers │ └── index.md │ ├── test-drive-your-first-istio-deployment-using-play-with-kubernetes-platform-cloud-computing │ └── index.md │ ├── the-importance-of-control-planes-with-service-mesh │ └── index.md │ └── xds-protocol │ └── index.md ├── 2019 ├── 01 │ ├── api-gateways-are-going-through-an-identity-crisis │ │ └── index.md │ ├── envoy-and-grpc-web-a-fresh-new-alternative-to-rest │ │ └── index.md │ └── istio-kubernetes-service-mesh │ │ └── index.md ├── 02 │ ├── back-to-microservices-with-istio-p1 │ │ └── index.md │ ├── cilium-1-4 │ │ └── index.md │ ├── envoy-threading-model │ │ └── index.md │ ├── faas-vs-microservices │ │ └── index.md │ ├── guidance-for-building-a-control-plane-to-manage-envoy-proxy-at-the-edge-as-a-gateway-or-in-a-mesh │ │ └── index.md │ ├── knative-whittling-down-the-code │ │ └── index.md │ ├── kong-mesh-analyse-report │ │ └── index.md │ └── using-istio-mixer-adapter-to-check-jwt │ │ └── index.md ├── 03 │ ├── application-metrics-in-istio │ │ └── index.md │ ├── back-to-microservices-with-istio-part-2-authentication-authorization │ │ └── index.md │ ├── building-a-control-plane-for-envoy │ │ └── index.md │ ├── circuit-breaking-and-outlier-detection-in-istio │ │ └── index.md │ ├── do-i-need-a-service-mesh │ │ └── index.md │ ├── hand-crafting-a-sidecar-proxy-like-istio │ │ └── index.md │ ├── microprofile-the-microservice-programming-model-made-for-istio │ │ └── index.md │ ├── microservices-circuit-breaker-pattern-implementation-istio-vs-hystrix │ │ └── index.md │ ├── prometheus-monitor-k8s-1 │ │ └── index.md │ ├── prometheus-monitor-k8s-2 │ │ └── index.md │ └── prometheus-monitor-k8s-3 │ │ └── index.md ├── 04 │ ├── automated-canary-deployments-with-flagger-and-istio │ │ ├── 0071hauBly1g1u72wr801j30rs0cdq4w.jpg │ │ ├── 0071hauBly1g1ubacxpukj30rs0mhjvg.jpg │ │ ├── 0071hauBly1g1ubdv033ej30rs0ap400.jpg │ │ ├── 0071hauBly1g1uc4hvoo6j30rs05ymy8.jpg │ │ └── index.md │ ├── benchmarking-istio-and-linkerd-cpu │ │ ├── 1.png │ │ ├── 2.png │ │ ├── 3.png │ │ ├── 4.png │ │ ├── 5.png │ │ ├── 6.png │ │ └── index.md │ ├── eight-things-leads-to-developing-catastrophic-cloud-native-microservices-system │ │ └── eight-things-leads-to-developing-catastrophic-cloud-native-microservices-system.md │ ├── envoy-service-mesh-and-observability-best-practices-for-enterprises │ │ └── index.md │ ├── gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative │ │ ├── gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative-1.png │ │ ├── gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative-2.png │ │ ├── gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative-3.png │ │ ├── gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative-4.png │ │ └── index.md │ ├── guidance-for-building-a-control-plane-for-envoy-part-3-domain-specific-configuration │ │ └── index.md │ ├── guidance-for-building-a-control-plane-for-envoy-part-4-build-for-extensibility │ │ └── index.md │ ├── istio-monitoring-explained │ │ └── index.md │ ├── the-service-mesh-era-istios-role-in-the-future-of-hybrid-cloud │ │ └── index.md │ └── what-is-a-service-mesh │ │ ├── index.md │ │ └── service-mesh-generic-topology.png └── 05 │ ├── canary-release-strategy-using-kubernetes-istio-and-helm │ ├── 0071hauBly1g262ptg24tj30i20c1t9p.jpg │ ├── 0071hauBly1g2uc247iboj315o0tndmy.jpg │ ├── 0071hauBly1g2ucct7lxoj315o0tnn58.jpg │ ├── 0071hauBly1g2ucjbe9lbj315o0tn10u.jpg │ ├── 0071hauBly1g2uclnkuu6j315o0tnahx.jpg │ ├── 0071hauBly1g2ucs0jxkxj315o0tnjzb.jpg │ ├── 0071hauBly1g2ucwd5qmaj315o0tnjz5.jpg │ ├── 0071hauBly1g2ud0nxutaj315o0tnwln.jpg │ └── index.md │ ├── deploying-envoy-proxy │ ├── envoy-blog-1.png │ ├── envoy-blog-2.png │ ├── envoy-blog-3.png │ ├── envoy-blog-4.png │ ├── envoy-blog-5.png │ └── index.md │ ├── istio-observability-with-go-gprc-and-protocol-buffers-based-microservices │ ├── 1.png │ ├── 10.png │ ├── 11.png │ ├── 12.png │ ├── 13.png │ ├── 14.png │ ├── 15.png │ ├── 16.png │ ├── 17.png │ ├── 18.png │ ├── 19.png │ ├── 2-1.png │ ├── 20.png │ ├── 21.png │ ├── 3.png │ ├── 4-1.png │ ├── 5.png │ ├── 6.png │ ├── 7.png │ ├── 8.png │ ├── 9.png │ └── index.md │ ├── kubernetes-service-mesh │ ├── arch.svg │ ├── empty-dashboard.png │ └── index.md │ └── preventing-systemic-failure-circuit-breaking-part-2 │ ├── cover.jpg │ ├── hystrix.png │ ├── index.md │ ├── monitor-control.png │ └── refine.png ├── .circleci └── config.yml ├── .github ├── auto-comment.yml ├── auto_assign.yml └── config.yml ├── .gitignore ├── .mergify.yml ├── .spelling ├── ISSUE_TEMPLATE.md ├── LICENSE ├── OWNERS ├── PULL_REQUEST_TEMPLATE.md ├── README.md ├── content ├── service-mesh-weekly-20180523-20180529.md ├── service-mesh-weekly-20180604-20180610.md ├── service-mesh-weekly-20180611-20180617.md ├── service-mesh-weekly-20180625-20180701.md ├── service-mesh-weekly-20180702-20180708.md ├── service-mesh-weekly-20180709-20180715.md ├── service-mesh-weekly-20180716-20180722.md ├── service-mesh-weekly-20180723-20180729.md ├── service-mesh-weekly-20180730-20180805.md ├── service-mesh-weekly-20180806-20180812.md ├── service-mesh-weekly-20180813-20180819.md ├── service-mesh-weekly-20180820-20180826.md ├── service-mesh-weekly-20180827-20180902.md ├── service-mesh-weekly-20180903-20180909.md ├── service-mesh-weekly-20180910-20180916.md ├── service-mesh-weekly-20180918-20180923.md ├── service-mesh-weekly-20180924-20181007.md ├── service-mesh-weekly-20181008-20181014.md ├── service-mesh-weekly-20181015-20181021.md ├── service-mesh-weekly-20181022-20181028.md ├── service-mesh-weekly-20181029-20181104.md ├── service-mesh-weekly-20181105-20181111.md ├── service-mesh-weekly-20181112-20181118.md ├── service-mesh-weekly-20181119-20181125.md ├── service-mesh-weekly-20181126-20181202.md ├── service-mesh-weekly-20181203-20181209.md ├── service-mesh-weekly-20181210-20181216.md ├── service-mesh-weekly-20181217-20181223.md ├── service-mesh-weekly-20181224-20181230.md ├── service-mesh-weekly-20181231-20190106.md ├── service-mesh-weekly-20190107-20190113.md ├── service-mesh-weekly-20190211-20190217.md ├── service-mesh-weekly-20190218-20190224.md ├── service-mesh-weekly-20190225-20190303.md ├── service-mesh-weekly-20190304-20190310.md ├── service-mesh-weekly-20190311-20190317.md ├── service-mesh-weekly-20190318-20190324.md ├── service-mesh-weekly-20190325-20190331.md ├── service-mesh-weekly-20190401-20190407.md ├── service-mesh-weekly-20190408-20190414.md ├── service-mesh-weekly-20190415-20190421.md ├── service-mesh-weekly-20190422-20190428.md ├── service-mesh-weekly-20190429-20190505.md ├── service-mesh-weekly-20190506-20190512.md ├── service-mesh-weekly-20190513-20190519.md ├── service-mesh-weekly-20190520-20190526.md ├── service-mesh-weekly-20190527-20190602.md ├── service-mesh-weekly-20190603-20190609.md ├── service-mesh-weekly-20190610-20190616.md ├── service-mesh-weekly-20190617-20190623.md ├── service-mesh-weekly-20190624-20190630.md ├── service-mesh-weekly-20190701-20190707.md ├── service-mesh-weekly-20190707-20190714.md ├── service-mesh-weekly-20190715-20190721.md ├── service-mesh-weekly-20190722-20190728.md ├── service-mesh-weekly-20190729-20190804.md ├── service-mesh-weekly-20190805-20190811.md ├── service-mesh-weekly-20190812-20190818.md ├── service-mesh-weekly-20190819-20190825.md ├── service-mesh-weekly-20190826-20190901.md ├── service-mesh-weekly-20190902-20190908.md ├── service-mesh-weekly-20190909-20190915.md ├── service-mesh-weekly-20190916-20190922.md ├── service-mesh-weekly-20190923-20190929.md ├── service-mesh-weekly-20190930-20191006.md ├── service-mesh-weekly-20191007-20191014.md ├── service-mesh-weekly-20191015-20191020.md ├── service-mesh-weekly-20191021-20191027.md ├── service-mesh-weekly-20191029-20191103.md ├── service-mesh-weekly-20191104-20191110.md ├── service-mesh-weekly-20191111-20191117.md └── service-mesh-weekly-20191118-20191124.md ├── docker └── circleci │ └── Dockerfile ├── mdl_style.rb └── scripts ├── lint_site.sh ├── mdl-check.sh └── mdspell-check.sh /.circleci/config.yml: -------------------------------------------------------------------------------- 1 | version: 2 2 | jobs: 3 | markdown-spell-check: 4 | docker: 5 | - image: shidaqiu/servicemesher-trans-circleci:1.0 6 | working_directory: ~/site 7 | steps: 8 | - checkout 9 | - run: 10 | name: Running markdown spell check 11 | command: scripts/mdspell-check.sh 12 | markdown-style-check: 13 | docker: 14 | - image: shidaqiu/servicemesher-trans-circleci:1.0 15 | working_directory: ~/site 16 | steps: 17 | - checkout 18 | - run: 19 | name: Running markdown style check 20 | command: scripts/mdl-check.sh 21 | workflows: 22 | version: 2 23 | workflow: 24 | jobs: 25 | - markdown-spell-check 26 | - markdown-style-check -------------------------------------------------------------------------------- /.github/auto-comment.yml: -------------------------------------------------------------------------------- 1 | # Comment to a new issue. 2 | issueOpened: > 3 | Thank your for raising a issue. We will try and get back to you as soon as possible. 4 | Please make sure you have given us as much context as possible. 5 | 6 | :laughing: 7 | pullRequestOpened: > 8 | Thank you for raising the pull request. We will review it as soon as possible. 9 | 10 | To ensure document quality, we have enabled the CI test, which currently includes spell and format checks. 11 | If your pull request fails to pass the spell check, but you are sure that the word(s) is/are correct, feel free to add the word(s) into our glossary [.spelling](https://github.com/servicemesher/trans/blob/master/.spelling). 12 | 13 | :laughing: 14 | -------------------------------------------------------------------------------- /.github/auto_assign.yml: -------------------------------------------------------------------------------- 1 | # Set to true to add reviewers to pull requests 2 | addReviewers: true 3 | 4 | # Set to true to add assignees to pull requests 5 | addAssignees: true 6 | 7 | # A list of reviewers to be added to pull requests (GitHub user name) 8 | reviewers: 9 | - haiker2011 10 | - loverto 11 | - malphi 12 | - rootsongjc 13 | - SataQiu 14 | - shaobai 15 | - x19990416 16 | 17 | # A list of keywords to be skipped the process that add reviewers if pull requests include it 18 | skipKeywords: 19 | - wip 20 | 21 | # A number of reviewers added to the pull request 22 | # Set 0 to add all the reviewers (default: 0) 23 | numberOfReviewers: 1 -------------------------------------------------------------------------------- /.github/config.yml: -------------------------------------------------------------------------------- 1 | # Configuration for new-issue-welcome - https://github.com/behaviorbot/new-issue-welcome 2 | 3 | # Comment to be posted to on first time issues 4 | newIssueWelcomeComment: > 5 | Thanks for opening your first issue here! Be sure to follow the issue template! 6 | # Configuration for new-pr-welcome - https://github.com/behaviorbot/new-pr-welcome 7 | 8 | # Comment to be posted to on PRs from first time contributors in your repository 9 | newPRWelcomeComment: > 10 | Thanks for opening this pull request! Please check out our contributing guidelines. 11 | # Configuration for first-pr-merge - https://github.com/behaviorbot/first-pr-merge 12 | 13 | # Comment to be posted to on pull requests merged by a first time user 14 | firstPRMergeComment: > 15 | Congrats on merging your first pull request! We here at behaviorbot are proud of you! 16 | # It is recommend to include as many gifs and emojis as possible -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | .DS_Store 2 | /.vs 3 | -------------------------------------------------------------------------------- /.mergify.yml: -------------------------------------------------------------------------------- 1 | pull_request_rules: 2 | - name: Automatic merge on CI success and review 3 | conditions: 4 | - "status-success=ci/circleci: markdown-spell-check" 5 | - "status-success=ci/circleci: markdown-style-check" 6 | - "#approved-reviews-by>=1" 7 | - label!=do-not-merge 8 | - label!=WIP 9 | actions: 10 | merge: 11 | method: squash 12 | strict: true 13 | -------------------------------------------------------------------------------- /2018/05/gitops-for-istio-manage-istio-config-like-code/index.md: -------------------------------------------------------------------------------- 1 | # Istio 的 GitOps——像代码一样管理 Istio 配置 2 | 3 | 在今年的哥本哈根 Kubecon 大会上，Weaveworks 的 CEO Alexis Richardson 与 Varun Talwar（来自一家隐形创业公司）谈到了 GitOps 工作流程和 Istio。会后 Weaveworks 的 Stefan Prodan 进行了的演示，介绍如何使用 GitOps 上线和管理 Istio 的金丝雀部署。 4 | 5 | 会谈和演示中解释了： 6 | 7 | - 什么是 GitOps？为什么需要它？ 8 | - Istio 和 GitOps 的最佳实践是如何管理在其上运行的应用程序的。 9 | - 如何使用 GitOps 工作流程和 Istio 进行金丝雀部署。 10 | 11 | ##什么是GitOps？ 12 | 13 | [GitOps 是实现持续交付的一种方式](https://www.weave.works/blog/the-gitops-pipeline)。“GitOps 使用 Git 作为声明式基础架构和应用程序的真实来源” Alexis Richardson 说。 14 | 15 | 当对 Git 进行更改时，自动化交付管道会上线对基础架构的更改。但是这个想法还可以更进一步——使用工具来比较实际的生产状态和源代码控制中描述的状态，然后告诉你什么时候集群的状态跟描述的不符。 16 | 17 | ## Git 启用声明式工具 18 | 19 | 通过使用 Git 这样的声明式工具可以对整套配置文件做版本控制。通过将 Git 作为唯一的配置来源，可以很方便的复制整套基础架构，从而将系统的平均恢复时间从几小时缩短到几分钟。 20 | 21 | ![](https://ws1.sinaimg.cn/large/00704eQkgy1fruc9ao41vj317o0oqq80.jpg) 22 | 23 | ## GitOps 赋能开发人员拥抱运维 24 | 25 | [Weave Cloud](https://cloud.weave.works/signup) 的 GitOps 核心机制在于 CI/CD 工具，其关键是[支持 Git 集群同步](https://github.com/weaveworks/flux/blob/master/site/introduction.md#automated-git-cluster-synchronisation)的持续部署（CD）和发布管理。Weave Cloud 部署专为版本控制系统和声明式应用程序堆栈而设计。以往开发人员都是使用 Git 管理代码和提交 PR（Pull Request），现在他们也可以使用 Git 来加速和简化 Kubernetes 和 Istio 等其他声明式技术的运维工作。 26 | 27 | ### GitOps 的三个核心原则 28 | 29 | 根据 Alexis 的说法，下面描述的是为何 GitOps 既是 Kubernetes 又是云原生核心的原因： 30 | 31 | #####1. GitOps 的核心是声明式配置 32 | 33 | 通过使用 Git 作为实体源，并使用 Kubernetes 做滚动更新，可以观察集群并将其与期望的状态进行比较。 [通过将声明性配置视为代码](https://www.weave.works/blog/gitops-operations-by-pull-request)，它允许您通过在未成功时重新应用更改来强制收敛。 34 | 35 | #####2. 不应该直接使用 Kubectl 36 | 37 | 根据一般规则来看，将代码经过 CI 直接 push 到生产并不是个好主意。许多人通过 CI 工具驱动部署，但是当你这样做的时候[你可能不得不做一个访问生产的东西](https://www.weave.works/blog/how-secure-is-your-cicd-pipeline)。 38 | 39 | #####3. 使用 operator 模式 40 | 41 | 通过 operator 模式，集群将始终与 Git 中签入的内容保持同步。Weave Flux 是开源的，它是使用 Istio 演示下面的金丝雀部署的基础，您可以使用 operator 管理集群中的更改。 42 | 43 | ![](https://ws1.sinaimg.cn/large/00704eQkgy1fruc9qogakj312t0ls41d.jpg) 44 | 45 | 无论是开发流程还是生产流程，还是从预发到合并到生产，operator 都会将更改 pull 到集群中，即使是有多个更改也能以原子的方式部署。 46 | 47 | ![](https://ws1.sinaimg.cn/large/00704eQkgy1fruca1y7xqj312p0jmn09.jpg) 48 | 49 | ## Istio 的 GitOps 工作流程 50 | 51 | 接下来，Varun Talwar 谈到了 Istio 是什么以及如何使用 GitOps 工作流管理应用程序。 52 | 53 | Istio 是一年前发布的服务网格。它是一个专用的基础设施层，用于为微服务架构中的所有服务间交互提供服务。Istio 中的所有操作都是通过声明式配置文件驱动的。也就是说像 Istio 这样的服务网格可以让开发人员在 Git 中像管理代码一样完全的管理服务行为。 54 | 55 | ![](https://ws1.sinaimg.cn/large/00704eQkgy1frucacq5nij317u0oo46y.jpg) 56 | 57 | 借助 Git 工作流程，开发人员可以对 Istio 中的任何内容进行建模，包括服务行为及其交互，如超时、断路器、流量路由、负载均衡及 A/B 测试和金丝雀发布等。 58 | 59 | ##跨团队的多组配置 60 | 61 | Istio 有四个广泛的领域应用，都是通过声明式配置驱动的： 62 | 63 | 1. 流量管理：与管理入口和服务流量有关。 64 | 2. 可观察性：监控、流量延迟、QPS、错误率等。 65 | 3. 安全性：所有服务间调用的认证与授权。 66 | 4. 性能：包括重试超时、故障注入和断路等。 67 | 68 | 因为所有这些领域都可以跨越组织内的不同团队，所以这使得在 Istio 上管理应用程序尤其具有挑战性。 69 | 70 | ![](https://ws1.sinaimg.cn/large/00704eQkgy1frucalfge7j317u0oq7aq.jpg) 71 | 72 | 这些配置驱动的很多设置是跨团队的。例如，有的团队想用 Zipkin 进行跟踪，而另一个团队可能想用 Jaeger。这些决策可以针对某一项服务进行，也可以跨服务进行。当决策跨越团队时，审批工作流程将变得更加复杂，并不总是原子性的。金丝雀发布不是原子的一次性事情。 73 | 74 | ## 通过 GitOps 工作流程在 Istio 上做金丝雀部署 75 | 76 | Stefan Prodan 向我们展示了如何使用带有 Weave Flux 和 Prometheus 的 GitOps 工作流程在 Istio 中做一次金丝雀发布——您可以在 Weave Cloud 中使用这些工具以及金丝雀部署和可观察性。 77 | 78 | 简而言之，当您想要用一部分用户测试某些新功能时，会使用金丝雀部署或发布。传统上，您可能拥有两台几乎完全相同的服务器：一台用于所有用户，另一台用于将新功能部署到某一组用户。 79 | 80 | 但通过使用 GitOps 工作流程，您可以通过 Git 控制您的金丝雀，而不是设置两个独立的服务器。当出现问题时，可以回滚到旧版本，并且可以在金丝雀部署分支上进行迭代，并继续发布，直到满足预期为止。 81 | 82 | ![](https://ws1.sinaimg.cn/large/00704eQkgy1frucatn3n3j312q0lw102.jpg) 83 | 84 | ### 在 Weave Cloud 中，Git 控制的金丝雀发布具有完全可观察性 85 | 86 | 通过流水线推送变更，您可以向用户发送部分一定比例的流量。使用 Weave Cloud，您可以在仪表板中观察金丝雀是否按预期工作。如果有问题可以继续修改，然后推出下一个版本，对其进行标记后通过同一流水线部署。这就是 GitOps 工作流程帮助您管理的迭代过程。 87 | 88 | ## 总结 89 | 90 | Alexis Richardson 给了我们关于 GitOps 的概述，以及为什么您需要在管理运行在 Kubernetes 和 Istio 上的应用程序时考虑这种方法。然后 Varun Talwar 谈到了 Istio 是什么以及如何使用 GitOps 工作流程来管理应用程序。最后，Stefan Prodan 向我们展示了一个特殊用例，其中非原子工作流程（如金丝雀发布）也可以通过像 Istio 这样的服务网格上的 GitOps 进行管理。 91 | 92 | 要全面观看演讲，请看下文。 93 | 94 | 95 | 96 | 97 | 98 | -------------------------------------------------------------------------------- /2018/05/microservices-docker-kubernetes-serverless-service/index.md: -------------------------------------------------------------------------------- 1 | # 微服务、Docker、Kubernetes、Serverless、Service Mesh 及更多 2 | 3 | 本文帮助您了解以上这些技术如何协同工作以实现更可靠、更高效的微服务开发和部署，以及 Ballerina 语言的作用。 4 | 5 | 所有这些都在这里。微服务因为基于容器的部署、服务网格实现和无服务器架构而成为现实。它们都是像Google、Lyft 和 Amazon这样的互联网巨头的概念和内部项目，并将其贯穿到整个企业生态系统中。基于容器的部署可以通过适当隔离应用程序运行时来优化资源利用率。这使得使用微服务风格开发的应用程序成为现实，并允许开发人员构建高效、可靠和高度分布式的企业应用程序，以满足像 Google、Uber 和亚马逊等公司的需求。 6 | 7 | Kubernetes 使基础设施成为一个更受控制、更可靠的实体，这样应用程序开发人员就不必担心基础设施部分的间歇性故障。它使您的数据中心成为一个单一的计算实体，您可以放心地部署应用程序。像亚马逊、微软和谷歌这样的云计算公司将 Kubernetes 作为一项服务提供给用户，以便用户可以直接在云中使用。 8 | 9 | 所有这些技术一旦成为了一个非常复杂的组件（服务器基础设施），就变成了一个简单而可靠可供应用程序开发者依赖的东西。这一发展的下一个阶段就是无服务器框架，您甚至不需要考虑基础设施的存在（又名 serverless）。相反，您可以编写自己的业务逻辑并将其交给云提供商，云提供商会将它们变成可供网络访问的端点或功能。 10 | 11 | 所有这些发展使得我们的企业生态系统需要连接为最终客户提供有意义的服务的众多端点。如果您在企业内部实施微服务架构，则需要确保正确地处理系统内的服务间通信。服务网格概念的出现就是为了试图通过数据平面来解决服务间通信问题，数据平面使得数据流经微服务网络和控制平面，该平面定义并控制这些微服务的连接。 12 | 13 | 这就是我们企业所拥有的。下一步是什么？上述技术提高了资源的可靠性、可扩展性和效率。所有这些技术使得企业越来越分散和分布式。现在一切皆终端，我们需要与众多的终端交互才能为客户提供有意义的服务。如何在这个高级系统之上构建应用程序？是否要回到单体的 ESB 或运行所有集成逻辑的消息代理？ 14 | 15 | 下一件大事就在这里！Ballerina 是专门为解决这个问题而构建的云原生编程语言。它带有直观的编程语法，内置支持集成了大量用例。Ballerina 允许你： 16 | 17 | - 以最小的努力建立集成（微）服务。 18 | - 处理来自现有系统的数据和事件并在不转换为规范数据格式的情况下自行转换它们。 19 | - 利用异步调用、断路器等先进技术处理终端故障。 20 | - 直接从带有注释的代码生成 Docker/Kubernetes 构件。 21 | - 构建以并行和异步方式运行多个任务的应用程序。 22 | - 以具有视觉吸引力的顺序图表示和查看程序。 23 | 24 | 除了上述功能外，Ballerina还配备了包括工具在内的全套生态系统： 25 | 26 | - 用于 VSCode、Vim 的 Ballerina Composer（IDE）和 IDE 插件等。 27 | - 为各个 Ballerina 程序实施测试的测试框架。 28 | - 生成 Ballerina 文档的文档生成框架。 29 | - Ballerina 中央共享存储库，可用于交换其他人编写的连接器和库。 30 | 31 | 你可以在[这里](https://ballerina.io/)了解更多关于 Ballerina 信息。 -------------------------------------------------------------------------------- /2018/05/the-path-to-service-mesh/index.md: -------------------------------------------------------------------------------- 1 | # 服务网格之路 2 | 3 | > 原文链接：https://blog.aspenmesh.io/blog/2018/03/the-path-to-service-mesh/ 4 | > 5 | > 作者：aspenmesh.io 6 | > 7 | > 译者：[卢宇亮](https://github.com/LJosef) 8 | 9 | ![](https://ws1.sinaimg.cn/large/007ackX3ly1frux62q06sj333415oqv5.jpg) 10 | 11 | 当我们谈论服务网格的时候，有几个问题经常被提及。这些问题的范围覆盖从简单的了解服务网格的历史，到产品和架构相关的比较深入的技术问题。 12 | 13 | 为了回答这些问题，通过 Aspen Mesh 之旅，我们带来三个主题的系列博文来讨论我们为什么选择了 Istio 。 14 | 15 | 作为开始，我将重点讨论我最经常被问到的问题之一： 16 | 17 | *为什么你选择服务网格，是什么原因促使你这样做？* 18 | 19 | #### **LineRate ：高性能负载均衡软件** 20 | 21 | 这个旅程起源于来自 Boulder 的初创公司 LineRate ，该公司在2013年被 F5 Networks 公司收购。 LineRate 除了是我曾经有幸参与的最聪明、最有才华的工程团队，还是一款轻量级高性能 L7 软件代理。当我说高性能时，我正在谈论的是如何将5年前在数据中心已经存在的服务器，变成一个高性能20+ Gbps 200,000+ HTTP 请求每秒的全功能负载。 22 | 23 | 虽然性能本身是引入注目的并为我们的客户打开了大门，但是我们的出发点在于客户期望付费的是容量，而不是硬件。这种见解是 LineRate 的核心价值主张。这个简单的概念将使我们的客户能够改变他们在应用之前使用和部署负载均衡的方式。 24 | 25 | 为了满足这个需求，我们交付了一种产品和商业模式，使我们的客户能够基于 COTS （可在市场上买到的）硬件按需多次复制他们的软件，从而不管部署多少实例都可以获得峰值性能。如果客户需要更多的容量，他们只需要简单的升级其订购层并部署更多的产品副本，直到达到他们许可证允许的带宽，请求速率或者交易速率。 26 | 27 | 这很有吸引力，我们也取得了一些成就，但是很快我们有了新的想法...... 28 | 29 | #### 效率优于性能 30 | 31 | 对于我们而言，应用架构正在发生变化，而客户的价值曲线随之变化的趋势也变得明显。我们在与资深团队沟通的过程中注意到，他们讨论的是诸如效率，敏捷，速度，印迹和横向扩展这类的概念。同时我们也开始听到这些领域的创新者开始采用Docker的新技术，以及它将如何改变应用和服务交付的方式。 32 | 33 | 我们与这些团队交流的越多，思考我们如何开发自己的内部应用程序，我们就越意识到转变正在发生。团队从根本上改变他们交付应用的方式，结果是我们的客户开始更少的关注原始性能而是更多地关心分布式代理。这些转变还有更多地收益，包含减少应用的故障域，增加部署的灵活性和赋予应用将负载和网络作为配置管理的能力。 34 | 35 | 与此同时容器和容器编排引擎也开始登上舞台，因此我们开始致力于通过一个新的控制面板以容器的方式交付 LineRate 的产品，并深入的思考人们未来会如何使用这些新技术来交付应用。 36 | 37 | 这些发生在2015的早期讨论促使我们思考未来应用交付将会如何...... 38 | 39 | #### 与时俱进的想法 40 | 41 | 随着我们对于未来应用交付方式的思考，我们开始关注云原声分布式应用领域中有关策略和网络服务的概念。尽管我们仍然有很多不同的优先级项目，改变应用蓝图，云原生应用和基于DevOps交付模式的想法始终在我们思想的最前端。 42 | 43 | 在这个领域将会有一个新的市场。 44 | 45 | 我们设计了许多项目，但由于种种原因未能成功。我们亲切的称这些项目为 v1.0 ，v1.5 和 v2.0 。每个项目都有一种解决分布式应用架构（微服务）挑战的独特技术。 46 | 47 | 我们尽最大可能去思考。下一个应用交付控制架构（ ADC ):一个完全与 API 驱动的控制面板和一个分离的数据面板。数据面板可能来自云你能够设想到的任意一种形式：靠近微服务的专用硬件，商用软件，或者云原生组件（就像服务网格）。这种无限可扩展的架构可以实现优雅的平衡，能够完美的工作于任意规模的任意组织的任意一种工作。很有野心吧？我们陷入了为客户提供所有东西的陷阱。 48 | 49 | 接下来，我们在“1.5”中完善了我们的方法，我们决定开发一种策略语言...... 关键是要定义开源的策略接口并将它无缝地连接到完成工作的数据路径。在一个真正开放的平台中，其中一些数据路径也是开源的。但是仍然有很多发展中的事情没有一步到位；事后看来，其中一些事情已经到来了...... 市场还没有到来，加上我们在开源方面也没有专业知识，于是我们在描述我们在做什么以及为什么时遇到了麻烦。 50 | 51 | 但是想法仍然在我们的脑海中燃烧，而我们也没有放弃...... 52 | 53 | 在 2.0 版本，我们设计了一个帮助希望开始容器之旅的 F5 的用户的计划。技术是新的，而市场也刚刚开始走向成熟，我们决定用户将会通过三步开启他们的微服务之旅。 54 | 55 | 1. *试验* - 在笔记本、服务器或者云主机上通过容器测试应用。 56 | 2. *生产规划* - 识别能够帮忙开发人员在生产环境部署容器化应用的技术。 57 | 3. *规模经营* - 重点关注容器应用的可观察性，可操作性和安全性，以减少平均停机发现时间 MTTD 和平均故障恢复时间 MTTR。 58 | 59 | 对于实验性用户我们做不了什么，但是对于生产规划，我们将创造一个开源的连接器，用来连接容器编排环境和 BIG-IP 。我们称之为 BIG-IP Container Connector，我们能够解决现有 F5 客户的问题，并和这些用户讨论下一步工作。BIG-IP ContainerConnector 的团队持续弥合在 ADC 和 快速改变的容器编排环境中的差距。 60 | 61 | 我们也开始开发一个新的轻量级容器化代理，称之为容器服务代理 （ Application Service Proxy ），或者 ASP 。 与 Linkerd 和 Envoy 类似的是，它被设计来促使微服务间的高效、灵活、可控的通信。与 Linkerd 和 Envoly 不同的是，它并没有开源社区。我们在考虑一种开源策略，同时它对于 ASP 意味着什么。 62 | 63 | 与此同时，F5 也在发生变化...... 64 | 65 | #### Aspen Mesh - F5 的创新 66 | 67 | 在我们开展 ASP 市场计划的同时，F5 通过孵化计划改变了投资新技术和新兴市场的方式。这两个事件与容器的爆炸性增长相结合，导致我们决定承诺在现有的开源服务网格之上构建产品。我们选择 Istio 是因为它具有吸引力的声明式策略语言，可扩展的控制平面架构以及其他我们将在更深入讨论时会涉及的内容。 68 | 69 | 计划已定，是时候将我们的想法推向我们力所能及的位置。Aspen Mesh 是这次推广的结果，也是一段历程的结局，同时也开启了一个新的篇章。 70 | 71 | 本系列文章的第二和第三章节将会重点讨论为什么我们决定将 Istio 作为我们服务网格的核心，和我们将会在未来的几个月内推出什么样的商业化的服务网格。 -------------------------------------------------------------------------------- /2018/06/8-ways-a-service-mesh-eases-microservices-deployment/index.md: -------------------------------------------------------------------------------- 1 | # 服务网格：8种方式简化微服务部署 2 | 3 | > 原文地址：https://thenewstack.io/8-ways-a-service-mesh-eases-microservices-deployment/ 4 | > 5 | > 作者：[Robert Whiteley](https://thenewstack.io/author/robert-whitely/) 6 | > 7 | > 译者：Grace 8 | 9 | 基于微服务的架构是未来的趋势，但是实现这种架构会面临许多困难。现代应用架构远比过去的架构复杂，因此实现微服务架构将会带来了一系列特殊的挑战，而服务网格可以帮我们解决很多问题。 10 | 11 | 最近一段时间，管理者不再专注于调试单个应用程序服务器，相反，现代系统就像是一群牛，研究整体的行为远比单个的服务器更有意义，分布式系统就是一个典型。 12 | 13 | 微服务是一种分布式架构，目的在于通过不断调整自身以适应当前流量状况的变化，例如，有一组处理客户端请求路由的容器，改变这组容器，反过来也意味着路由表在不断变化，由此反映了应用程序端点的变化位置。与此同时，在任何架构体系中都会有过去的遗留物，从必须使用单个大型数据库服务器的应用程序到捆绑API以使其看起来是以服务为重点的遗留系统。 14 | 15 | 而服务网格是当前最先进的微服务模式。它建立在容器以及容器编排之上，配有处理内部服务通信的专用控制面。它负责协调分布式网格的微服务所需的安全性，路由，身份验证，授权和类似功能，服务网格将这些功能从应用程序（或应用程序的服务组件）中剥离出来作为可编程的基础组件。虽然不是所有的公司都需要如此复杂的服务网格（尽管这些公司大部分都运行着成百上千的服务），但服务网格正迅速成为那些希望运行生产级微服务的公司的默认架构。 16 | 17 | 以下是八种实现服务网格的方法，可以帮助您平滑过渡到微服务。 18 | 19 | 1. **改进微服务的消息处理机制**。服务网格确保你能监控到整个架构层，不仅可以跟踪到网络中的服务器地址，还可以跟踪到传达服务器地址信息的消息。例如，你可能想要跟踪“失败”消息，但这些消息在传统云架构中通常会丢失。服务网格的好处是既可以确保消息的传递，又会在消息未到达目的地时返回错误信息。 20 | 2. **利用与传统应用程序相同的运维方式**。对于企业级网络来说，可定制性和灵活性是最重要的。服务网格是为适应现代分布式应用程序而设计的。但是底层的技术如入口控制器，负载均衡器，以及代理都和传统单体应用的数据层面的技术相同。在实现服务网格的过程中，组织可以利用到与运营现代、基于软件的应用程序交付基础设施相同的技术与技能。 21 | 3. **灵活使用多种云服务**。服务网格解决了现代应用的云网络问题。支撑起服务网格的数据平面和控制平面的技术独立于任何特定架构，因此它们可以在无论是裸机，容器还是虚拟机的公有或私有的架构上运行。这种灵活特性甚至允许服务网格处理未来的应用程序架构，从而发挥其规模化、全球复制以及深层性能调节等优势。您的服务网格将成为运作模式化云架构场景下，一切潜在优势的实现保障。 22 | 4. **提高对微服务的可见性**。分布式系统的指标对于我们而言就像是一个黑盒子，而网格服务为我们提供了一种更深入观察分布式系统的指标的途径。它会随时间收集性能指标，为团队提供服务可用性的长期指标。这为操作员提供了一种观察服务可靠性和性能的方式，使他们能够逐步优化系统。 23 | 5. **更高效的运维以及更有效的执行SLA（服务等级协议）**。服务网格提供的追踪功能对调试和故障排除至关重要，与此同时，它也确保服务执行了服务等级协议（SLA）。服务网格执行了很多任务，包括执行策略以及追踪查看这些策略是否被满足。它为管理者提供了一个可以在网络层实施云应用管理和策略的场所。 24 | 6. **简化微服务实现**。服务网格的另一大优点是可以轻松部署它们。过去的解决方案要求开发人员将服务内功能编码到每个微服务中。这需要重写应用程序并在不同的编程语言中维护各种库。而服务网格帮开发人员抽象了这些事务。开发人员可以简单地调用必要的消息传递和服务发现功能就可以轻松的部署它们，而微服务的源码只用包含业务逻辑相关的代码。 25 | 7. **加快新服务的上线时间**。过去的库解决方案，如Finagle、Hystrix和Stubby，需要开发人员长时间的介入并且迫使开发人员将冗余功能编码到每一个服务中。另一个更简单的方法是在每个微服务中放置一个sidecar代理并将它们连接在一起，这正是服务网格所擅长的，因此未来将会有更多的云应用选择服务网格架构。简而言之，服务网格保证了开发者的生产力，使他们能够更快地将更多的服务推向市场。 26 | 8. **保障服务间的通信安全**。服务之间通信有可能跨云，跨数据中心，或者跨大陆，而服务网格保障了这些通信的安全，它封装了所有的通信，并且在控制器层面协调这些通信，通过管道内加密，联系人策略和服务权限解决了安全问题。 27 | 28 | --- 29 | 30 | 译文原地址：https://mp.weixin.qq.com/s/Q-k0BtUz2U4bWiXXdeaw7g -------------------------------------------------------------------------------- /2018/06/containers-service-mesh-and-api-gateways-it-starts-at-the-edge/index.md: -------------------------------------------------------------------------------- 1 | # 容器、服务网格和 API 网关：从边缘开始 2 | 3 | [Docker](https://www.docker.com/) 和 [Kubernetes](https://kubernetes.io/) 为代表的容器技术炙手可热，熟知这一技术领域的用户，一定都知道下一个热点：Service Mesh，它承诺将微服务之间的内部网络通信均一化，并解决一系列监控、故障隔离等通用非功能性需求。底层的代理服务器技术是 Service Mesh 的立身之本，这种技术在 Service Mesh 之外，还能以 API 网关的形式在边缘为业务系统提供一系列的增强。 4 | 5 | 虽说 Service Mesh 的爆发之势让人误以为罗马是一日建成的，事实上，在这一热点浮出水面之前，包括 [Verizon](https://getnelson.github.io/nelson/)、[eBday](https://fabiolb.net/) 以及 [Facebook](https://code.facebook.com/posts/1906146702752923/open-sourcing-katran-a-scalable-network-load-balancer/) 在内的很多组织已经在应用后来被我们称之为 Service Mesh 的技术了。这些早期应用 Service Mesh 的组织之一就是 [Lyft](https://www.microservices.com/talks/lyfts-envoy-monolith-service-mesh-matt-klein/)，这是一家年收入超过十亿美元的美国网约车巨头。Lyft 还是开源软件 [Envoy Proxy](https://www.envoyproxy.io/) 的诞生地，Envoy 在 Service Mesh 世界中举足轻重，Kubernetes 原生的 [Istio 控制面](https://istio.io/docs/concepts/what-is-istio/overview/) 和 [Ambassador API 网关](https://www.getambassador.io/) 也都建筑在 Lyft 的基础之上。 6 | 7 | ## SOA 网络的烦恼 8 | 9 | Matt Klein 是 Envoy Proxy 的作者之一，他去年的一次谈话中说到，SOA（面向服务的架构）和微服务网络是“[混乱的庞然大物](https://www.microservices.com/talks/lyfts-envoy-monolith-service-mesh-matt-klein/)”。身处其中的每个应用都输出了不同的统计和日志，整个服务堆栈如何处理请求生成响应的过程也是无法跟踪的，在这样的情况下进行 Debug 的巨大难度也就可以想象了。同时对类似负载均衡器、缓存以及网络拓扑这样的基础设施组件的监控能力也是很有限的。 10 | 11 | 他觉得：“这很痛苦，我认为多数公司都赞同 SOA（微服务）是个可见趋势，在这一趋势的践行过程中会收获很多，但是其中也满是痛苦。主要的痛苦来源就是 Debug”。 12 | 13 | 对于大规模组织来说，分布式 Web 应用的可靠性和高可用支持是一个核心挑战。这种挑战的应对方式中，普遍包含包含重试、超时、频率控制和熔断等功能逻辑的各种实现。很多系统，不论开源与否，都会使用锁定特定语言（甚至锁定框架）的形式来实现这种方案，这就意味着开发人员也同时被进行锁定。Klein 和他在 Lyft 的团队认为，一定有更好的办法。最终 Envoy 项目诞生了。 14 | 15 | ## 外部干预：边缘代理的优势 16 | 17 | [2016 年 9 月](https://eng.lyft.com/announcing-envoy-c-l7-proxy-and-communication-bus-92520b6c8191) 以开源形式发布了 Envoy Proxy，Klein 和 Lyft 工程师团队一夕成名，但这并非一蹴而就，Lyft 架构从最初的混合 SOA 架构起步，花费了四年，突破层层险阻升级为服务网格治理之下的微服务体系。2017 年的[微服务实践者虚拟峰会](https://www.microservices.com/talks/mechanics-deploying-envoy-lyft-matt-klein/)上，Klein 讲述了向服务网格进行技术迁移的过程中面对基本需求和相关挑战，及其商业价值。 18 | 19 | Klein 的第一次艰苦取胜是“从边缘代理开始”的。微服务为基础的 Web 应用需要在边缘提供反向代理，一方面可以防止暴露内部业务服务接口（会违反松耦合原则），另一方面，暴露大量服务也意味着大量的独立 URI 以及 RPC 端点，这会消耗大量的运维资源。现存的云所提供的边缘代理服务器或者网关都不很好，不同产品呈现给工程师的是不同的、易混淆的工作界面。Klein 倡议在边缘实现一个现代化的代理服务，在其中提供改进的监控、负载均衡以及动态路由能力，以此来产生商业价值。工程师团队理解和掌握了边缘代理的运维之后，就可以向内部团队进行推广，最终形成内部的服务网格了。 20 | 21 | ## 边缘进化：从代理到 API 网关 22 | 23 | AppDirect 是一个端到端提供云端产品和服务管理的商业平台，预计年收入 5000 万美元。在 AppDirect 最近的博客 [Evolution of the AppDirect Kubernetes Network Infrastructure](https://www.appdirect.com/blog/evolution-of-the-appdirect-kubernetes-network-infrastructure) 中，他们着重介绍了和 Lyft 类似的经历。云技术和 Kubernetes 之类的编排平台带来的不只是有规模、弹性之类的好处，还因为与生俱来的易变和动态特性，提出了新的挑战：微服务构建的商业功能如何合适的在公共端点上提供服务？ 24 | 25 | AppDirect 工程师团队采用了一种可靠的方法来应对挑战，首先把配置的核心部分（例如暴露的服务端口）静态化，然后在每个应用之前部署负载均衡器。接下来的迭代就是使用 HashiCorp 的分布式键值库 [Consul](https://www.consul.io/) 结合支持热重载的 HAProxy 反向代理来提供更好的动态管理能力。团队的终极目标是用更丰富功能的 API 网关来提供更丰富的功能。 26 | 27 | 文中说到：“API 网关的目标是在不变更已公开 API 的访问性的情况下（这种不经变更的可访问性也包含了旧有的 URL 以及友商的定制域名等），通过注入和替换的方式逐个实现转换过程。” 28 | 29 | 在对一系列的开源和商业产品进行评估之后，AppDirect 团队选择了构建在 Envoy proxy 之上的 Kubernetes 原生的 Ambassador API 网关产品： 30 | 31 | “构建于我们了解和喜爱的 Kubernetes API 之上的 Ambassador，是一个轻量、稳定以及没有外部数据库依赖的产品。Ambassador 很独特，使用 Kubernetes 对象标注功能来定义路由配置（也就是以此实现 [Envoy 数据面](https://blog.envoyproxy.io/the-universal-data-plane-api-d15cec7a)的控制平面）”——团队博客如是说。 32 | 33 | 虽然 AppDirect 还没有完全实现内部通信的网格化，但是已经感受到了 Envoy Proxy 这样的技术所带来的好处，更学到了在产品中应用这些技术的能力。 34 | 35 | ## 星火燎原 36 | 37 | 服务网格技术的实现和迁移过程才刚刚开始，但是已经可以肯定，这一技术弥合了 Kubernetes 这样的现代容器化平台中应用之间的鸿沟。服务网格带来的，包括频率控制、断路器以及监控性等在内的所有好处，都可以从服务边缘开始享用。如果想要对这一技术进行进一步的探索和学习，在系统边缘开始，农村包围城市是一种行之有效的策略。这种策略无需全面部署，就能迅速的在监控、弹性等方面展示出特有的商业价值。 -------------------------------------------------------------------------------- /2018/06/making-most-out-microservices-service-mesh/index.md: -------------------------------------------------------------------------------- 1 | # 利用服务网格充分利用微服务 2 | 3 | ![](https://ws1.sinaimg.cn/large/61411417ly1fsgj45r133j20m80aumyx.jpg "mesh") 4 | 5 | Aspen Mesh的Andrew Jenkins说，转向微服务本身并不能消除复杂性。 6 | 7 | 在本文中，我们与Aspen Mesh的首席架构师Andrew Jenkins谈论了如何从单一应用程序转向微服务，并通过一些关于服务网格的宣传来管理微服务架构。有关服务网格的更多信息，请考虑参加于2018年5月2日至4日在丹麦哥本哈根举行的[KubeCon + CloudNativeCon EU](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2018/attend/register/)。 8 | 9 | **1.微服务解决了许多公司面临的单体架构问题。你认为其最大的价值在哪里？** 10 | 11 | **Andrew Jenkins** ： 对我来说，这是关于最小化时间对用户的影响。向虚拟化和云转型的关键是降低与支持应用程序的所有基础架构相关的复杂性，以便您可以灵活地分配服务器和存储等。但是这种转变并不一定会改变我们构建的应用程序。现在我们有了灵活的基础架构，我们应该构建灵活的应用程序以充分利用它。 12 | 13 | 微服务是灵活的应用程序——构建小型，单一用途的模块并快速构建它们，以便您可以快速将它们交付给最终用户。组织可以使用它来根据实际用户需求进行测试并迭代构建。 14 | 15 | **2.随着企业从单体应用程序向微服务迁移，收益显而易见，但公司在采取行动时遇到的一些挑战是什么？** 16 | 17 | **Jenkins** ： 转向微服务本身并不能消除复杂性。任何一个微服务的复杂性都很小，但是整个系统都很复杂。从根本上说，公司希望知道哪个服务正在与哪个服务对话，代表哪个服务对象，然后能够使用策略来控制该通信。 18 | 19 | ![](https://ws1.sinaimg.cn/large/61411417ly1fsgj488frxj20ed05zgnh.jpg "微服务") 20 | 21 | **3.组织如何尝试应对这些挑战？** 22 | 23 | **Jenkins** ： 一些公司从第一天起就将这种可见性和策略部分添加到他们构建的每个应用程序中。当公司投资于定制工具、工作流程、部署管理和 CD 管道时，这种情况尤其常见。我们也发现这些公司通常是以几种语言为导向，并且几乎写出他们自己运行的所有内容。 24 | 25 | 如果您的应用程序堆栈是多边形的，并且是新开发和迁移现有应用程序的组合，则很难证明将这些部分单独添加到每个应用程序是合理的。来自不同团队和外部开发的应用程序的应用程序更多地提高了这一点，一种方法是分别对待那些不符合要求的应用程序 - 将它们置于策略执行代理之后，或者从可见性角度将它们视为更多的黑盒子。但是，如果你不必做出这种分离，那么如果有一种简单的方法来获得任何语言的任何应用程序的原生式策略和可见性，那么你可以看到它的优势。服务网格就是这样的一种方法。 26 | 27 | **4.作为管理微服务架构的最终解决方案，围绕服务网格存在大量宣传。你的想法？** 28 | 29 | **Jenkins** ：是的，这绝对是攀登炒作循环曲线。它不会适合所有情况。如果你已经有微服务，并且你觉得你有很好的控制能力和可视性，那么你已经有了一个很好的开发人员工作流程，那么你就不需要把所有东西都撕掉，并且明天在服务网格中填充。我建议你可能仍然想知道里面的内容，因为当你的团队处理新的语言或环境时它可能会有帮助。 30 | 31 | 我认为我们应该了解服务网格如何将功能集成到一个一致的层中。我们都喜欢保持我们的代码干爽（不要重复自己）。我们知道两个相似的实现永远不会完全相同。如果您可以利用服务网格来获得一个可以在整个基础架构中运行的重试逻辑的实现，那么真正简化了开发人员，操作人员以及与该系统一起工作的每个人的操作。我敢打赌，你的团队中没有人想再写一个重试循环的副本，特别是没有人想调试用go编写的文件和用python编写的文件之间的细微差别。 32 | 33 | **5.随着要监控的服务数量的增加，这些服务中的每一个很可能：** 34 | 35 | **- 使用不同的技术/语言** 36 | 37 | **- 住在不同的机器/容器上** 38 | 39 | **- 拥有自己的版本控制** 40 | 41 | **服务如何解决这些差距？** 42 | 43 | **Jenkins** ：Service mesh的第一个承诺是为任何语言编写的微服务（对于任何应用程序堆栈）执行相同的操作（即可见性和控制部分）。接下来，当您考虑不同的容器互相交谈时，服务网格可能会帮助与该层相关的许多内容。例如，你是否相信保护每个单独运行的容器而不是外围（防火墙）安全？然后使用服务网格提供从容器到容器的mTLS。 44 | 45 | 我还看到，版本控制差异是更深的应用程序生命周期差异的表现。所以这个团队使用这样的版本控制，广泛的资格认证阶段和谨慎的升级策略，因为他们提供了每个人都依赖的最核心的服务之一。另一个从事全新原型服务的团队有一个不同的政策，但您肯定希望确保他们不写入生产数据库。将他们的“方形挂钩工作流程”装入你的“圆孔工艺”并不是正确的。 46 | 47 | 您可以使用服务网格以适合他们的方式将这些不同的应用程序和服务移植到系统中。现在显然你想要使用一些判断，而不是为每一个小的微服务定制固定，但我们听到很多关于服务网格的兴趣，以帮助消除这些生命周期和期望之间的差异。再次，它的全部是提供快速迭代，但不放弃可见性和控制。 48 | 49 | **6.控制平面与数据平面：服务网格为每个平面提供值？** 50 | 51 | **Jenkins** ：今天开始制作网络服务是多么容易。您可以将代码放入推文中。虽然这不是真正的 Web 服务。为了使其具有弹性和可扩展性，您需要在应用程序的数据平面添加一些内容。它需要做 TLS，它需要重试失败，它只需要接受来自这个服务的请求，但不是那个，并且它需要检查用户的认证，等等。服务网格可以帮助您获得数据平面功能，而无需向应用添加代码。 52 | 53 | 而且，由于现在已经在数据平面层中，因此可以在不修改应用程序的情况下升级和增强该层。 54 | 55 | 服务网格为您的微服务带来了控制平面的一致性。像 Kubernetes 这样的容器编排系统提供了描述你想要运行哪些容器的常用方法。这并不是说你不能在没有它们的情况下运行容器，那是因为一旦你运行了一些容器，你就需要一个一致的方式来运行它们。服务网格就是这样，用于容器之间的通信。 56 | 57 | **7.服务网格的流行语是“可观察性”。你能分享一下真实世界中的可观察性提供的好处吗？** 58 | 59 | **Jenkins** ：我们曾与一个团队谈过，他们告诉我们他们花了几个小时的时间在电话上试图解决一些跨越很多服务和组件的问题。他们从每项服务中收集了大量数据，他们知道答案是在某处的大量数据中。但是他们花了很多时间在信息的每个快照之间进行翻译。他们不相信翻译中的每一步都是正确的 - 毕竟，如果他们明白发生了什么事情，他们首先会设计出这个问题。最重要的是，哪里开始寻找并不总是很清楚。 60 | 61 | 他们要求的是一种观点 - 一个地方收集的所有服务信息，以及他们问题最重要的信息。同样，服务网格不是万能的，我不会保证你永远不必再看日志文件。但我的目标是，一旦这个团队拥有一个服务网格，他们总是有信心，他们已经对每一个微服务进出的内容有了很好的观察，并且服务网格已经指出他们正确的方向。 62 | 63 | 对我而言，可观察性不仅仅是收集大量数据点。这是为了尽快将智能大脑应用于系统中的真实故障。 64 | 65 | **8.您对服务网格的未来有什么看法？** 66 | 67 | **Jenkins** ： 我认为各种实现都提供了一个引人注目的策略和组件工具箱。我很高兴我们正在利用从微服务的先驱获得的经验教训来构建这个通用服务网格层。 68 | 69 | 下一步将选择如何使用该工具箱来解决问题。组织希望在部署策略方面保持一定的一致性：面临的挑战是将应用开发者，信息安全平台和平台团队的利益结合起来，以便他们的所有策略都融合在服务网格中。 70 | 71 | 在技术细微差别上，我们已经看到了服务网格，它们利用所谓的 Sidecar 模型来集成和服务没有的网格。Sidecar 对于应用增强层感觉很自然，但我们并不习惯于那些我们认为是基础设施的层。 72 | 73 | 一旦我们从第一天开始依赖服务网格来编写应用程序，我们就有机会对应用程序进行细粒度但高级别的控制。每一个应用程序都将具有先进的重试逻辑、安全性、可见性等，从第一天开始。首先，这将改变我们开发和测试应用程序的方式。我认为这也将为我们还没有想到的跨应用策略敞开大门。 74 | -------------------------------------------------------------------------------- /2018/06/manage-microservices-traffic-using-istio/index.md: -------------------------------------------------------------------------------- 1 | ##使用 Istio 为微服务提供高级流量管理和请求跟踪功能 2 | 3 | >原文地址：https://developer.ibm.com/code/patterns/manage-microservices-traffic-using-istio/ 4 | > 5 | >作者：IBM 6 | > 7 | >译者：[Jimmy Song](https://jimmysong.io) 8 | 9 | ##说明 10 | 11 | 开发人员正在摆脱大型单体应用的束缚，转而采用小巧而专一的微服务，以加速软件开发并加强系统弹性。为了满足这个新生态的需求，开发人员需要为部署的微服务创建一个具有负载均衡、高级流量管理、请求跟踪和连接功能的服务网络。 12 | 13 | ##概述 14 | 15 | 如果您花时间开发过应用程序，那么有件事情您肯定明白：单体应用正成为过去。当今的应用程序都是关于服务发现、注册、路由和连接。这给微服务的开发和运维人员提出了新的挑战。 16 | 17 | 如果您的服务网格在规模和复杂性上不断增长，您可能想知道如何理解和管理服务网格。我们也遇到了同样的问题：如何使这些越来越多的微服务能够彼此连接、负载均衡并提供基于角色的路由？如何在这些微服务上启用传出流量并测试金丝雀部署？仅仅创建一个独立的应用程序还不够，所以我们该如何管理微服务的复杂性呢？ 18 | 19 | Istio 是 IBM、Google 和 Lyft 合作创建的项目，旨在帮助您应对这些挑战。Istio 是一种开放技术，它为开发人员提供了一种这样的方式：无论是什么平台、来源或供应商，微服务之间都可以无缝连接，服务网格会替您管理和保护微服务。在下面的开发之旅中，您将了解如何通过 Istio 基于容器的 sidecar 架构提供复杂的流量管理控制功能，它既可用于微服务之间的互通，也可用于入口和出口流量。您还将了解如何监控和收集请求跟踪信息，以便更好地了解您的应用流量。此次开发者之旅对于所有使用微服务架构的开发人员来说都是理想之选。 20 | 21 | ## 流程 22 | 23 | ![IStio部署和使用流程图](https://ws1.sinaimg.cn/large/00704eQkgy1fs1ew7msf1j32kn19zwmb.jpg) 24 | 25 | 1. 用户在 Kubernetes 上部署其配置的应用程序。应用程序 `BookInfo` 由四个微服务组成。该应用中的微服务使用不同的语言编写——Python、Java、Ruby 和 Node.js。`Reivew` 微服务使用 Java 编写，有三个不同的版本。 26 | 2. 为了使应用程序能够利用 Istio 的功能，用户将向微服务中注入 Istio envoy。Envoy 使用 sidecar 的方式部署在微服务中。将 Envoy 注入到微服务中也意味着使用 Envoy sidecar 管理该服务的所有入口和出口流量。然后用户访问运行在 Istio 上的应用程序。 27 | 3. 应用程序部署完成后，用户可以为示例应用程序配置 Istio 的高级功能。要启用流量管理，用户可以根据权重和 HTTP 标头修改应用的服务路由。在该阶段，`Review` 微服务的 v1 版本和 v3 版本各获得 50％ 的流量；v2 版本仅对特定用户启用。 28 | 4. 用户配置服务的访问控制。为了拒绝来自 v3 版本的 `Review` 微服务的所有流量对 `Rating` 微服务的访问，用户需要创建 Mixer 规则。 29 | 5. 完成应用程序的部署和配置后，用户可以启用遥测和日志收集功能。为了收集监控指标和日志，用户需要配置 Istio Mixer 并安装所需的 Istio 附件 Prometheus 和 Grafana。要收集 trace span，用户需要安装并配置 Zipkin 附件。 30 | 6. 用户为 `Bookinfo` 创建一个外部数据源；例如 IBM Cloud 中的 Compose for MySQL 数据库。 31 | 7. 原始示例 `BookInfo` 应用程序中的三个微服务——`Details`、`Ratings` 和 `Review` ，已修改为使用 MySQL 数据库。要连接到 MySQL 数据库，需要在 `Details` 微服务中添加了一个 MySQL Ruby gem；向 `Ratings` Node微服务中添加 MySQL 模块。将 `mysql-connector-java` 依赖项添加到 `Reviews` 微服务 v1、v2 和 v3 版本中。 32 | 8. 用户部署应用程序并启用具有出口流量的 Envoy 代理。Envoy 代理作为 sidecar 跟每个微服务部署在一起。Envoy sidecar 将管理该服务中所有流入和流出的流量。当前情况下，由于 Envoy 仅支持 http/https 协议，因此通过提供 MySQL 的 IP 地址范围，代理配置将不会拦截到 MySQL 连接的流量。当应用程序启动后，用户可以使用 IP 和节点端口访问应用程序。 33 | 34 | 查看该示例中的代码：https://github.com/IBM/microservices-traffic-management-using-istio -------------------------------------------------------------------------------- /2018/06/rate-limiting-a-useful-tool-with-distributed-systems-part1/index.md: -------------------------------------------------------------------------------- 1 | # 速率限制——分布式系统的一个实用工具part1 2 | 3 | > 原文链接：https://blog.getambassador.io/rate-limiting-a-useful-tool-with-distributed-systems-6be2b1a4f5f4 4 | > 5 | > 作者：Daniel Bryant 6 | > 7 | > 译者：戴佳顺 8 | > 9 | > 审校：宋净超 10 | 11 | 在计算领域，速率限制通常用于控制服务发起或消耗的操作速率，或者是请求发送或接收的流量。如果你有一年以上的软件开发经验，那么你应该会遇到这个概念。 但是，和很多软件架构所面临的挑战一样，比起实际出现的问题，需要思考的问题会更多。 本文概述了现代分布式应用程序中的一些关于速率限制的实现方案、优势和挑战。 12 | 13 | ## 为什么需要速率限制？ 14 | 15 | 实现速率限制主要是由于以下三个原因：通过资源节制防止（有意无意的）拒绝服务，限制（潜在的）级联故障的影响，以及限制或计量资源的使用情况。 16 | 17 | [Twitter](https://developer.twitter.com/en/docs/basics/rate-limiting) 或 [Ebay](https://go.developer.ebay.com/api-call-limits) 这样的企业组织使用了一种类似的拒绝服务防治模式：在SaaS API之前放置一个速率限制器，以此来避免针对API后端的拒绝服务恶意攻击，同时也可以为所有消费者提供一致的服务。在那些支付API（如 [Stripe](https://stripe.com/blog/rate-limiters) ）的减负策略中可以使用速率限制来防止级联故障（通过系统中的一些组件部分降级）。同样，当为外部信息源轮询例像健康检查这些新数据时，也会使用限制（或计量）模式。这样我们只需要定期获取数据，并可以为启动的每个请求付费。 18 | 19 | ## 如何选择？ 20 | 21 | 基于简化的原则，我们假设正在处理点对点通信模型中的速率限制。在这种场景下，你可以在数据发送的“发送端”或数据消费“接收端”中的任何地方实施速率限制，当然还有其他“中间件”选项： 22 | 23 | ![发送端和接收端](https://ws1.sinaimg.cn/large/78a165e1gy1fsmq2gb6qhj20lp05wmx4.jpg) 24 | 25 | - 你可以控制发送端发送请求的速率 ：通过定义时间限制循环来定期发送API请求。 26 | 27 | - 你可以控制接收端接收请求的速率：在当前任务/线程处理完成之前拒绝新的入站HTTP连接。 28 | 29 | ![控制速率](https://ws1.sinaimg.cn/large/78a165e1gy1fsmq7eltt3j20rc06tdfv.jpg) 30 | 31 | - 你可以使用中间层来缓冲发送的请求：通过将请求放入队列（可以通过定义不同优先级，为请求提供不同级别的SLA）。 32 | 33 | ![请求缓冲](https://ws1.sinaimg.cn/large/78a165e1gy1fsmq8on7a0j20lr07eaa2.jpg) 34 | 35 | - 你可以使用中间层来限制发送的请求：通过使用某种形式的代理或网关。这样当下游服务不再接受请求时，它会切换至断路器。 36 | 37 | ![中间层](https://ws1.sinaimg.cn/large/78a165e1gy1fsmq9qjzycj20jk06tdgn.jpg) 38 | 39 | ## 如何权衡？ 40 | 41 | 如果你正在开发一个需要解决上述问题的系统，可以参考如下方案，并清楚定义在哪些地方（及相应组件）需要实现速率限制。 42 | 43 | 另一方面，如果你只控制其中一端（比如只控制接收端或只开放公用API），那么你的选择余地就会受到限制，因为你不能依赖现有的设计指南或设计原则（即使系统不包含恶意使用者）。即使你同时控制了两端，你可能仍然想要实现“双保险”，实现同时包括两端的速率限制。 44 | 45 | 其他需要权衡点包括： 46 | 47 | ### 发送端和接收端的处理速率限制的能力 48 | 49 | - 有时由于开发模型或可用资源限制等原因，不可能在组件内实施有效的速率限制。 50 | 51 | - 在分布式系统中，单个组件的速率限制可能无法提供所需的功能（至少在一定程度上需要其他协调）。例如，如果你的速率限制了某个请求发送端进行连接，你需要横向扩展至两个发送端来满足需求，这样导致允许的发送端变为两个。 52 | 53 | - 你可能也不希望后端服务工程师开发速率限制功能，因为这样可能会由于定制开发而引起不同技术栈的差异。 54 | 55 | - 如果应用程序负载过重，可能需要将所有速率限制功能放到应用外，以避免在应用中执行速率限制功能导致其性能损失。 56 | 57 | - 我相信你听说过“单一职责”原则。因此在粗颗粒度架构级别，你可能会要求在应用外的组件里提供像速率限制这样的辅助功能。 58 | 59 | ### 速率限制中间件的故障模式 60 | 61 | - 你有必要知道速率限制服务崩溃（服务启动失败或被关闭）时会发生什么？如果服务能缓冲请求，你可能需要定义服务重启策略（期间的请求需要被缓冲至磁盘）。 62 | 63 | ### 速率限制中间件的算法灵活性 64 | 65 | - 自己实现基于发送端或接收端速率限制功能的主要优势在于是你可以完全控制速率限制算法的实现方式。例如，[令牌桶](https://en.wikipedia.org/wiki/Token_bucket) 、 [固定窗口](https://blog.figma.com/an-alternative-approach-to-rate-limiting-f8a06cf7c94c) 、 [滑动窗口](https://blog.figma.com/an-alternative-approach-to-rate-limiting-f8a06cf7c94c) 以及通过请求（元）数据来进行算法决策。 66 | 67 | - 你需要经常评估哪些算法可以与外部速率限制服务一起“开箱即用”，同时确定是否需要其他外部数据（包括关联的元数据处理）。 68 | 69 | ## 案例 70 | 71 | 更具体一点，我们来看几个例子。 72 | 73 | ### 运行一个任务来调用第三方SDK，每次调用都具有请求限制，同时按计量收费（即你控制发送端，但无法控制接收端）。 74 | 75 | 对于请求限制和按计量收费的方案，我希望实施本地（发送端）速率限制。假设请求超过了速率限制，那么可能会收到一个错误，或者可能被（暂时）阻止。我因此需要确认SLA或检查生产实施文档。无论发生什么，我都不会希望我的应用程序简单地在不断尝试循环连接，因为是这只会浪费我的资源。如果发送端没有基于计量收费的速率限制，我会付出很多钱，而且没有人愿意这样做！ 76 | 77 | 在Java语言中，我经常使用Google开源的 Guava RateLimiter 库来解决这类问题。我写的发送端的应用程序示例就像下面这样： 78 | 79 | ![Guava案例](https://ws1.sinaimg.cn/large/78a165e1gy1fsmqalcy5zj20kv03gglu.jpg) 80 | 81 | 这是一个基于 [Guava RateLimiter JavaDoc](https://google.github.io/guava/releases/19.0/api/docs/index.html?com/google/common/util/concurrent/RateLimiter.html) 的简单示例，实际上我可能在任务执行逻辑中增加一些异常处理块。 82 | 83 | ### 提供一个公共API （即你控制接收端，但无法控制（全部）发送端） 84 | 85 | 在这种场景下，可以防止API后端过载的唯一方法是通过对接收端进行速率限制，最好是将限制功能放到如API网关这类外部服务上。 86 | 87 | ![API Gateway](https://ws1.sinaimg.cn/large/78a165e1gy1fsmqcco3umj20h80bemxj.jpg) 88 | 89 | ## 结论 90 | 91 | 通过这篇速率限制文章的三部分，我们了解了速率限制的动机、可以选择的方案和相关的权衡。在下一篇文章中，我将详细介绍如何实现API网关的速率限制算法！ 92 | -------------------------------------------------------------------------------- /2018/06/the-rise-of-the-istio-service-mesh/index.md: -------------------------------------------------------------------------------- 1 | # Istio服务网格的崛起 2 | 3 | > 原文链接：https://www.infoworld.com/article/3273547/containers/the-rise-of-the-istio-service-mesh.html 4 | > 5 | > 作者：Diogenes Rettori 6 | > 7 | > 译者：戴佳顺 8 | 9 | 如何确保微服务之间网络通信的可靠性、安全性和可管理性？ 使用服务网格吧！ 10 | 11 | 在过去一年中，[Istio](https://istio.io/)服务网格技术引发关注度和吸引力的持续提升，这是一件非常有趣的事情。 事实上，在我写这篇文章时，Istio仅为0.8版本，但对于最近两届[KubeCon/CloudNativeCon](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2018/)活动而言，它一直是[热门话题](https://events.linuxfoundation.org/events/kubecon-cloudnativecon-europe-2018/program/schedule/)，仅在丹麦的活动中就有超过十几个不同的活动议题。 那么它为什么会这样受欢迎？ 12 | 13 | 在深入研究Istio受欢迎的原因之前，让我们先来介绍一下服务网格。 这是一个通用术语，其早已被投入在多个不同场景中。例如定义不同无线设备之间的通信方法；或者定义一个系统，各个应用程序可以直接通过它与其他应用程序通信。[最近](https://istio.io/docs/concepts/what-is-istio/overview.html)，这个术语被用来表示应用或微服务的网络，以及它们之间的互相作用关系。后者是本文的重点。 14 | 15 | 事实上红帽公司一直参与云原生和微服务领域建设，包括四年前决定将OpenShift向Kubernetes和Docker转变，这帮助我们理解了服务网格技术，尤其是Istio的重要性。本文将探讨为什么我会坚信Istio会很受欢迎的四个原因。 16 | 17 | ## 微服务和转型 18 | 19 | 纵观你整个职业生涯，或者结合如今的工作，你可能已经发现从代码完成开发到部署至生产之间的时间不断被延长，以至于开发资源被转移到其他项目，同时也使你的产品反馈周期变得无效或无关紧要。为了缩短交付时间，一些公司决定以功能服务架构或微服务架构来将大型应用拆散，以此提高效率。即曾经具有多种功能的单个应用程序（包）被切分成可独立更新的单个程序包。 20 | 21 | 这当然是有价值的，但同时也要承认，使用这种架构需要对单独的服务和它们之间的接口进行更多的开发治理。例如曾经定义在应用程序内部的一部分API调用关系现在上升在到网络层中。 22 | 23 | Christian Posta的演讲“[微服务中最困难的部分：调用你的服务](https://www.slideshare.net/ceposta/the-hardest-part-of-microservices-calling-your-services)”谈到了一个重要问题。当调用API时，你可能会认为你在处理A和B之间的直接集成调用（下图1）。然而计算机网络并不会针对直接通信进行优化（下图2）。因此在某些情况，尤其当应用处于你正考虑或使用的云环境中时，你不可避免且不得不考虑这些不同的失控物理和虚拟网络设备。例如，就可能存在这样一种情况：其中一台设备的性能低于最佳性能，这将影响整个应用程序的响应时间（下图3）。 24 | 25 | ![A和B之间的调用关系图](https://ws1.sinaimg.cn/large/78a165e1gy1fs7fmkvibwj20jf0dfq40.jpg) 26 | 27 | ## 微服务先驱和Netflix OSS 28 | 29 | 有些公司似乎是为了云计算而生的。为了在云中提供弹性服务，应用程序不得不保护自己免受环境异常影响。 30 | 31 | Netflix构建并随后[开源](https://netflix.github.io/)了一系列涉及诸如断路、边缘路由、服务发现和负载均衡等功能的Java技术解决方案。这些组件使应用能够更好地控制通信，从而提高整体可用性。为了测试并确保组件的弹性，Netflix还使用了[混沌工程](http://principlesofchaos.org/)，通过将各种现实中可能存在的问题注入到应用程序的网络中，以便能在任何给定时间中断工作流。 Netflix开发的技术组合允许其应用程序投入到一个以应用程序为中心的网络中，这实际上就是服务网格。 32 | 33 | 在构建Netflix OSS堆栈的时代，虚拟机是在云中运行应用程序的唯一方式。因此Netflix选择Java作为开发语言来构建服务网格功能。 34 | 35 | 除了Netflix OSS堆栈的纯Java依赖，另一个挑战是为了实现服务网格功能，开发人员必须将Java库包含在其应用程序中，并在代码中引用来使用这些组件。但在当时，那些希望强制使用这些技术的公司无法在平台级进行如上工作。 36 | 37 | 随着[Kubernetes](https://www.infoworld.com/article/3268073/containers/what-is-kubernetes-container-orchestration-explained.html)的来临，诸如服务发现和负载均衡等功能成为平台本身的一部分，并且平台允许用任何语言编写的应用程序都可以使用。通过声明式和活动状态管理，Kubernetes还能够通过自动重启无响应的应用来提高整体应用的可用性。在当今世界，Kubernetes和容器是运行微服务应用程序的标准。 38 | 39 | 在Kubernetes中，你的应用程序以由一个或多个容器组成“pod”运行。在pod中运行多个容器的技术有时也被称为“sidecar”，其实质上是一种将你的应用程序拆散，将子模块运行在共享隔离空间（pod）的解决方案。 40 | 41 | Kubernetes为Istio这样的技术的崛起创造了有利条件。出行共享公司Lyft已经开始通过智能代理[Envoy](https://github.com/envoyproxy/envoy)来提供微服务部署所需的弹性和动态路由功能。 sidecar容器和Envoy这类架构允许为每个应用程序实例附加一个轻量级代理，以支持服务发现、负载均衡、断路器、链路跟踪以及服务网格的其他功能。将它与一个控制面板结合，并添加服务治理和Envoy实例配置管理功能，你就拥有了Istio。 42 | 43 | ## 拥抱分布式架构 44 | 45 | 最后，Istio和服务网格通常与“拥抱”[分布式计算的谬论](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)有关。 换而言之，”**Istio允许应用程序假定网络是可靠的、快速的、安全的、不变的等等——这使得分布式计算的谬论不再是谬论** “。说Istio和Kubernetes可以解决所有这些问题，但忽视这些谬论可能导致企业犯大错误。 企业必须接受这样一个事实：当你有多个微服务和功能服务互相交互时，你就处理分布式系统。 46 | 47 | 请参阅下面的分布式计算谬论的完整列表以及Istio的解决方案： 48 | 49 | | 谬论 | Istio的解决方案 | 50 | | ---------- | ----------------------------- | 51 | | 可靠网络 | 断路和负载均衡 | 52 | | 延迟为零 | 超时和重试 | 53 | | 忽略带宽 | 服务评级和限制 | 54 | | 安全网络 | 相互TLS | 55 | | 拓扑不可改 | 服务发现 | 56 | | 单一管理员 | 基于角色的访问控制 | 57 | | 零传输成本 | gRPC和Protobuf | 58 | | 同质化网络 | 动态路由，A/B测试和金丝雀部署 | 59 | 60 | 在我与OpenShift客户的沟通中，我经常发现他们由于自身需求，已经实现了类似Netflix模式的功能。我也对实现这些功能的团队很有兴趣，经常听到他们说“我们是断路小组”或“我们是服务发现小组”。 61 | 62 | 创建自己的服务网格功能的公司现在有机会使用Kubernetes和Istio。通过使用这些被标准化的开源技术，他们可以获得由大型社区开发的功能、整理知识和用例，并帮助他们实现更具弹性的应用程序，同时以更低的成本更快地将产品推向市场。 63 | 64 | 作者Diogenes Rettori是[红帽OpenShift](https://www.redhat.com/en/technologies/cloud-computing/openshift)的主任产品经理。在加入OpenShift团队之前，他专注于红帽JBoss中间件的客户培训。 Diogenes拥有强大的工程背景，曾为爱立信和IBM等公司工作。 65 | -------------------------------------------------------------------------------- /2018/06/twistlock-makes-istios-security-layer-more-robust-easier-to-monitor/index.md: -------------------------------------------------------------------------------- 1 | # Twistlock使Istio的安全层更强大，更易于监控 2 | 3 | > 原文地址：[Twistlock Makes Istio’s Security Layer More Robust, Easier to Monitor](https://thenewstack.io/twistlock-makes-istios-security-layer-more-robust-easier-to-monitor/) 4 | > 5 | > 译者：[宋净超](https://jimmysong.io) 6 | 7 | Istio已经成为一种流行且可靠的服务网格管理平台，使用它可以更轻松地部署、操作和扩展跨云部署的微服务。作为保证这些服务网格的一种方式，Twistlock已经与Istio集成，以丰富平台的连接机器学习功能。 Twistlock通过使用Twistlock数据来隔离受损服务并提供合规策略来执行安全配置，以及Istio运行的其他堆栈。 8 | 9 | 随着云原生成为构建和运行现代的基于Web的大规模应用程序的默认方式，组织需要越来越复杂的工具来将基本复杂性从日常操作中抽象出来。Kubernetes显然是编排调度军备竞赛的赢家，并且已经提炼出了管理大型计算节点的复杂性。但是，由于Kubernetes可以实现更大规模的部署，因此我们可以利用其平台级别原语的配套技术使管理大型服务组合变得更简单。 10 | 11 | 例如，使用Kubernetes您可以轻松部署应用程序并将其扩展到1000个节点的集群，并处理部署和节点故障。但是，为该服务路由流量、监控服务的整体运行状况（而不仅仅是单个节点和pod）以及确保该服务与集群内其他服务之间的公平资源分配可能很复杂。 12 | 13 | [Istio](https://istio.io/)是一个旨在补充Kubernetes（和微服务平台）并提供上述功能的项目。更具体地说，Istio旨在为微服务提供流量管理、服务标识、管理策略实施和遥测。 14 | 15 | Istio是围绕托管在[云原生计算基金会（CNCF）](https://cncf.io)中开源的[Envoy proxy](https://www.envoyproxy.io/) 而构建的项目。Istio建立在现有Kubernetes能力的基础上，使部署更为熟悉和集成，同时提供超越Kubernetes基础设施所关注的各种增值服务。 16 | 17 | 在过去的几个月中，我们的客户越来越多地询问Twistlock关于Istio的计划，今天我们很高兴分享这些细节。 Istio是一个复杂的平台，具有多种配置选项和安全设置，在处理所有细节时很容易迷失。 18 | 19 | 尽管开始运行Istio非常简单，但能够了解流量流，实施安全最佳实践以及（可能最重要的）利用Istio提高应用安全性的能力是我们关注的重点领域。 20 | 21 | ##示例场景 22 | 23 | 为了探索Twistlock提供的新安全功能，我们将使用大家耳熟能详的[Bookinfo](https://istio.io/docs/guides/bookinfo)示例应用程序。如指南中所述，此应用由多个互连的微服务组成： 24 | 25 | - `productpage`微服务调用`details`和`reviews`微服务来填充页面; 26 | - `details`微服务包含书籍信息; 27 | - `reviews`微服务包含书评。它也称为`ratings`微服务; 28 | - `ratings`微服务包含伴随书评的书籍排名信息。 29 | 30 | 该应用程序的拓扑结构如下所示： 31 | 32 | ![istio bookinfo为服务拓扑图](https://ws1.sinaimg.cn/large/00704eQkgy1fs7h9ansyfj30r30j40uw.jpg) 33 | 34 | ##可视化和控制雷达视图上的Istio 35 | 36 | 我们在使用Istio的客户中意识到的第一个挑战就是可视化服务的拓扑结构。尽管Twistlock一直提供雷达视图来为您的整个容器化环境提供实时Visio，但Istio允许我们以更多的应用特定知识和深度进一步增强这些数据。 37 | 38 | ![istio可视化拓扑](https://ws1.sinaimg.cn/large/00704eQkgy1fs7hau83l5j30r30dyn0t.jpg) 39 | 40 | **Istio的主要安全优势之一是严格控制的网络策略——即严格控制通信协议和实体之间的连接。**为此，建议在Istio中启用[服务级别访问控制](https://istio.io/docs/tasks/security/role-based-access-control/)。在Twistlock中使用此功能时，您可以直接在雷达的可视化界面中获得对网络拓扑的完全可视性和控制。 41 | 42 | 例如，在Bookinfo示例中，`productpage`服务具有一个绑定到`productpage-viewer`的`product-viewer`角色和一个`details-reviews-viewer`服务角色。 43 | 44 | 第一个角色表示所有用户都可以访问产品页面，而第二个角色是为产品页面明确设置的，并且只允许访问details和ratings服务。 45 | 46 | Twistlock会自动注册整个配置，以便动态更新并注释到每个服务的Radar界面上： 47 | 48 | ![twistlock radar界面](https://ws1.sinaimg.cn/large/00704eQkgy1fs7hld5v39j30r30dwwjb.jpg) 49 | 50 | 此外，单击服务角色时，可以查看每个角色的详细信息： 51 | 52 | ![istio radar界面](https://ws1.sinaimg.cn/large/00704eQkgy1fs7hm2a3tgj30r30dd786.jpg) 53 | 54 | 使用Twistlock，我们可以编辑和管理与给定实体关联的所有安全设置，并查看Istio管理服务网格拓扑中反映的更改。 55 | 56 | ##利用Istio进行运行时隔离 57 | 58 | 我们还把运行时防御传感器与Istio集成在一起，通过分析实体间允许的连接和基础架构元数据，在覆盖拓扑中添加深度安全智能。我们利用这些数据，根据网络元数据和观察到的行为异常来提供报告和隔离实体。 59 | 60 | 例如，如果在Bookinfo应用程序中，攻击者成功过的破解了`productpage`服务并从那里访问`ratings`服务，那么会发生什么？从技术上讲，如果所有网格规则配置正确，Istio网络策略可能会阻止连接，但您仍然需要关注日常的检测和警告，这是通过CNNF（我们L3云原生网络防火墙）与Istio集成： 61 | 62 | ![](https://ws1.sinaimg.cn/large/00704eQkgy1fs7hm2a3tgj30r30dd786.jpg) 63 | 64 | 当然，这些网络违规也会在雷达中报告和显示： 65 | 66 | ![istio radar](https://ws1.sinaimg.cn/large/00704eQkgy1fs7i4zhla0j30r30fewi7.jpg) 67 | 68 | 该流程中将利用Twistlock的ML驱动的行为建模来自动检测异常情况，随后让Istio关闭该服务的响应以隔离受损的服务。 69 | 70 | 例如，Twistlock可以在检测到异常时通过指示Istio断开该服务与后端支付数据库的连接以隔离面向公众的Web服务。由于此集成发生在服务网格层，因此Istio可以即时并优雅地在整个环境中执行它，而无需更改IP路由或手动重新配置端口。 71 | 72 | ## Istio合规 73 | 74 | 最后，我们的Twistlock Labs研究团队已经为Istio开发了一系列新的合规性检查。这些合规性检查与Istio项目和社区中的现有最佳实践保持一致，例如确保在生产namespace中启用相互TLS，并启用严格的基于角色的访问控制（RBAC）。这些合规性策略符合Twistlock现有的合规性功能，包括出现不合规情况时的提醒和阻止的能力，以及在Compliance Explorer仪表板中实时查看全局状态。 75 | 76 | ##总结 77 | 78 | 随着客户部署和运行的云原生应用程序越来越复杂，像Istio这样的平台补充了Docker和Kubernetes的现有功能，为每个客户提供行星际尺度的工具。Twistlock通过为Istio添加一个安全层，并利用它来扩展整个服务网格的安全性，有助于扩展Istio的适用范围。 79 | 80 | --- 81 | 82 | 关于[Twistlock](https://www.twistlock.com)：**Twistlock**通过先进的智能和机器学习功能，保护当今应用免受未来的威胁，并自动制定政策和执行。作为第一个端到端的容器安全解决方案，Twistlock专门用于提供现代化的安全性。 -------------------------------------------------------------------------------- /2018/07/ab-testing-on-kubernetes-with-istio-0-8/index.md: -------------------------------------------------------------------------------- 1 | # 使用 Istio 0.8 对 Kubernetes 进行 A/B 测试 2 | 3 | > 原文地址： 4 | > 5 | > 作者：[Alessandro Valcepina](https://medium.com/@alessandrovalcepina) 6 | > 7 | > 译者：[张琦翔](https://github.com/zhangqx2010) 8 | > 9 | > 校对：[宋净超](http://jimmysong.io) 10 | 11 | ![](https://ws1.sinaimg.cn/large/7134983fgy1ft55myd1kej20kb098dft.jpg) 12 | 13 | 这是我们正在发布的系列文章中的第二篇，描述了我们在 Kubernetes 上采用 Istio 进行流量路由的经验。有关我们试图通过Vamp实现的更多详情以及我们选择 Istio 的原因，请参阅我们的[第一篇文章](https://medium.com/vamp-io/putting-istio-to-work-8513f5218c51)。 14 | 15 | 最近几个月对 Istio 社区来说相当令人兴奋。随着 0.8 版本的发布，该平台变得更加稳定，现在受益于更加一致（尽管仍然粗糙）的设计。然而，这些改进的代价是路线配置更加复杂。 16 | 17 | Vamp Lamia 这个新版本的目标是将 Istio 从 0.7.1 迁移到 0.8 并让它使用起来更加简单。与此同时，我们希望提供一种有助于某种现实场景应用的新功能。 18 | 如今，许多产品经理希望通过 A/B 测试来测试页面上新功能的价值。不幸的是，这通常来说都很难做到。 19 | 通常人们最终会以离线的方式处理复杂系统，功能切换或日志系统。往往所有这些情况都依赖于人工干预，从而成为一个缓慢，容易出错的过程，也不能很好地与 CI/CD管道集成。 20 | 21 | 当我们开始工作时，我们问自己：有多少工作可以在不用写编码的情况下自动完成？ 22 | 23 | 进入 Vamp Lamia 0.2.0。 24 | 25 | 我们解决这个问题的方法的核心是实验（Experiment）的概念。 26 | 实验是在 Vamp Lamia 管理的服务上设置基于 cookie 的 A/B 测试的简便方法。它们只需要非常基本的配置，根本不需要编码。 27 | 为简单起见，我们假设您有一个电子商务网站，并且您已经听说如果页面背景是蓝色时客户会购买更多东西，而网站当前的背景为红色。你想测试这个假设，如果证明这一点是真的，那就使用金丝雀发布的方式转向蓝色背景。 28 | 29 | 为此，您必须部署要测试的两个版本并标记它们，例如，“version1” 和 “version2” 。 Vamp 将选择这两个 deployment，并允许您创建 Service，以及绑定到它的Destination Rule 和 Gateway。 30 | 这些实体所起作用的详细说明超出了本文的范围，您可以在[Istio 文档](https://istio.io/docs/)中找到更多信息。 31 | 现在，足以说 Gateway 是 Istio 对于 Kubernetes Ingress 的等价替代品，因此能让服务在对外暴露，而 Destination Rule 将 deployment 上的标签映射到 subset，提供了一层抽象用于更好地将不同版本的服务分组。 32 | 正如您在下面的屏幕截图中所看到的，只需一些易于理解的参数即可轻松设置这些资源。 33 | 34 | ![](https://ws1.sinaimg.cn/large/7134983fgy1ft55odj8ffj20m80f1aas.jpg) 35 | 36 | *服务设置* 37 | 38 | ![](https://ws1.sinaimg.cn/large/7134983fgy1ft55p32bxmj20m80jwaay.jpg) 39 | 40 | *网关设置* 41 | 42 | ![](https://ws1.sinaimg.cn/large/7134983fgy1ft55pf1l3dj20m80sedgz.jpg) 43 | 44 | *目标规则设置* 45 | 46 | 完成此操作后，您可以开始设置实验本身，例如使用下面显示的配置。 47 | 48 | ![](https://ws1.sinaimg.cn/large/7134983fgy1ft55purozaj20m80ukq47.jpg) 49 | 50 | *实验设置* 51 | 52 | 大多数字段都是不言自明的，但是为了清楚起见，让我们逐一说明： 53 | 54 | - **服务名称（Service Name）** 是您要在其上运行A/B测试的服务的名称。 55 | - **服务端口（Service Port）** 是要使用的服务端口。 56 | - **网关名称（Gateway Name）** 是暴露服务的网关。 57 | - **以分钟为单位的时间段（Period in minutes）** 是以分钟为单位的时间间隔，用于定期更新配置。 58 | - **步长（Step）** 是每次更新时权重的变化量。 59 | - **标签（Tags）** 是与特定服务版本相关的描述性值。 60 | - **子集（Subset）** 是服务的子集。 61 | - **目标（Target）** 检查的URL用于评估特定子集的成功率。 62 | 63 | 实验将通过检查在到达登陆页面后打开目标页面的用户数来测试功能的性能。 64 | 为了跟踪这一点，Vamp Lamia 为访问登陆页的每个用户设置了一个 cookie，然后检查同一用户是否访问了目标页面。 65 | 所有这一切都可以实现，因为一旦创建实验，Vamp Lamia 将负责建立一个新的 Virtual Service 绑定到提供的 Service 和 Gateway。 66 | 67 | Virtual Service 是 Istio 0.8 中 Route Rule 的替代品，用于定义指定 Service 的流量路由。 68 | 您可以在以下屏幕截图中查看其配置。 69 | 70 | ![](https://ws1.sinaimg.cn/large/7134983fgy1ft55qfs20zj20m80ob0ug.jpg) 71 | *虚拟服务配置* 72 | 73 | 我们意识到这种配置可能会让人觉得相当含糊，所以让我们一起来看一下。 74 | 75 | Virtual Service 定义了三条路由。前两个很容易理解：它们各自指向一个已部署的版本。第三个是在两个版本的 Cookie 服务器之间均衡负载。 76 | 此配置的目的是将新访问者引向 Cookie 服务器，然后将 Cookie 设置为将其标识为特定用户并将其分配给其中一个已配置的 subset。 77 | 完成此操作后，Cookie 服务器会将用户重定向回原始 URL，从而返回 Virtual Service。但是，由于这次的请求具有 Subset Cookie，会适配到前两条路由的其中之一，根据路由设置的条件，用户被转发到登录页面的特定版本。这是使用标准 HTTP 重定向完成的，因此开销很低，用户不会遇到任何中断。 78 | 此外，由于我们依赖 cookie，我们能够在继续测试的同时为用户提供一致的体验，这意味着在短时间内来自同一用户的后续请求将始终使用相同的版本。 79 | 80 | 根据测试结果，在 Virtual Service 上定义的策略将使更多用户移动到更成功的版本，即用户达到登陆页面后访问了目标网页的总数比率更高的版本。 81 | 例如，让我们假设蓝页对大多数客户来说更好。虽然最初客户将在两个版本中平均分配，但随着时间的推移和结果的出现，流量将会发生变化。将向更多客户分配通往蓝页的 cookie，并且由于 cookie 是有时间限制的，因此先前已分配到红色页面的客户将逐渐转向表现更好的版本。 82 | 83 | 可以通过指标页面监控此行为，如下所示。 84 | 85 | ![](https://ws1.sinaimg.cn/large/7134983fgy1ft55re75e9j20m80egmy0.jpg) 86 | 87 | *虚拟服务指标* 88 | 89 | 这里介绍的情景当然仍然过于简单。在接下来的几周内，我们将不再涉及 subset 和版本的概念，以便更多地关注用户想要测试的功能，我们将转向 [Welch’s t-test](https://en.wikipedia.org/wiki/Welch％27s_t-test) 算法，用于识别表现最佳的版本。同时，我们还计划自动创建 Gateway 和 Destination Rule，以便在用户不需要特定配置时隐藏所有复杂性。 90 | 91 | 以上就是这次的分享！请随时向我们提供有关此新功能以及Vamp Lamia发展方向的反馈，请不要忘记，如果您想更深入地了解 Vamp Lamia 功能，请查看我们 [github](https://github.com/magneticio/vamp2setup) 上的 repo。 92 | -------------------------------------------------------------------------------- /2018/07/how-service-mesh-addresses-3-major-microservices/index.md: -------------------------------------------------------------------------------- 1 | # Service Mesh 如何解决微服务中的3个主要挑战 2 | > 原文链接：https://dzone.com/articles/how-service-mesh-addresses-3-major-microservices-c 3 | > 4 | > 作者：[Zach Jory](https://twitter.com/zjory) 5 | > 6 | > 译者：[李昕阳](https://darrenxyli.com/) 7 | > 8 | > 审校：[宋净超](https://jimmysong.io) 9 | 10 | **我们都知道微服务会增加复杂性。 了解服务网络如何解决这一问题和其他挑战。** 11 | 12 | 我最近正在阅读 Dimensional Research 撰写的[全球微服务趋势报告](https://go.lightstep.com/global-microservices-trends-report-2018)，在阅读的同时，我个人也认为“服务网络可以帮助解决这个问题。”所以我将阐述这3个挑战以及服务网格是如何解决它们。报告中引用的受访者表明微服务正在得到广泛采用。同样清楚的是，除了微服务带来的无数好处之外，同样也带来了一些严峻的挑战。报告显示： 13 | 14 | - 91％的企业**正在使用**微服务或有计划使用 15 | - 99％的用户认为在使用微服务时遇到了**挑战** 16 | 17 | ## 微服务主要的挑战 18 | 该报告指出了公司面临的一系列挑战。 19 | 20 | ![](https://ws1.sinaimg.cn/large/855e972fly1fto3iki07wj20zh0d9404.jpg) 21 | 22 | 大量公司既面临着技术上的挑战，同时也面临着组织结构上的挑战。而我将专注于能够用服务网格解决的技术挑战，但值得注意的是，服务网格所做的一件事就是带来一致性，因此可以在团队之间实现相同的愿景，从而减少对某些技能的需求。 23 | 24 | ## 每个额外的微服务都会增加运维的难度 25 | 如果没有服务网格，这句话将成为现实！服务网格可以通过 API 提供监控，可伸缩性和高可用性，而不是通过分离设备。这种灵活的框架消除了与现代应用相关的操作复杂性。基础设施服务传统上是通过分离设备实现的，这意味着需要到达实际的设备来获得服务。因为每个设备的唯一性，导致为每个设备提供监控，扩展和高可用性有很高的难度。服务网格通过 API 在计算集群内部提供这些服务，不需要任何其他设备。实现服务网格意味着添加新的微服务不必增加复杂性。 26 | 27 | ## 识别性能问题的根本原因更加困难 28 | 服务网格工具箱为您提供了一些有助于解决此问题的方法： 29 | 30 | ### 分布式跟踪 31 | 跟踪为不同的微服务提供服务依赖性分析，并在请求穿梭于多个微服务时跟踪此请求。它也是识别性能瓶颈和放大特定请求以定义诸如哪些微服务导致请求延迟或哪些服务产生错误之类的事情的好方法。 32 | 33 | ### 指标的集合 34 | 通过服务网格能够获得的另一个有用的功能是收集指标的能力。指标是在各个时间维度上了解应用程序中发生了什么，以及何时它们是健康的或者不健康的关键。服务网格可以从网格中收集遥测数据，并为每一跳产生一致的指标。这样可以更轻松地快速解决问题，并在将来构建更具弹性的应用程序。 35 | 36 | ![](https://ws1.sinaimg.cn/large/855e972fly1ftobpzbxnzj20rl0b2mya.jpg) 37 | 38 | ## 不同的开发语言和框架 39 | 报告受访者指出的另一个主要挑战是在多语言世界中维护分布式架构的挑战。当从单体服务到微服务的转变时，许多公司都面临着一个现实就是，他们必须使用不同的语言和工具来让系统工作起来。大型企业尤其受此影响，因为他们拥有许多大型分布式团队。服务网格通过提供编程语言不可知性来提供一致性，这解决了多语言世界中的不一致性，其中不同的团队（每个团队都有自己的微服务）可能使用不同的编程语言和框架。网格还提供了统一的、覆盖整个应用程序的观测点，用于将可见性和控制性引入应用程序，同时将服务间的通信从隐含的基础架构领域移出到一个可以轻松查看，监视，管理和控制的位置。 40 | 41 | ![](https://ws1.sinaimg.cn/large/855e972fly1ftobqt0wv7j20ry0ce0uc.jpg) 42 | 43 | 微服务很酷，但服务网格使得它更酷。如果您正处于微服务的路途中并且发现难以应付基础架构挑战，那么服务网格可能是正确的答案。如果您对如何充分利用服务网格有任何疑问，请告诉我们，我们的工程团队随时可以与您交流。 44 | -------------------------------------------------------------------------------- /2018/07/k8-istio-little-deep-dive/index.md: -------------------------------------------------------------------------------- 1 | # 深入浅出 Istio 2 | 3 | > 原文地址： 4 | > 5 | > 作者：Jeronimo (Jerry) Garcia 6 | 7 | 我一直在使用Istio的egress，但是今天我想讨论的是ingresses。 8 | 9 | Istio的ingress是使用一些可以互相通信的代理（例如envoy），来处理应用中的访问，限制和路由等。 10 | 11 | 真正有趣的是Istio使用sidecar注入的方式。想象一下你运行了一个监听在80端口上的nginx容器，Istio会在相同的pod中注入一个sidecar容器，这个容器使用特权模式和NET\_ADMIN功能来共享内核网络命名空间。 12 | 13 | 通过以上方式，Istio保证全链路追踪或者交互TLS等能力。 14 | 15 | 简单来说，Istio的工作流程看起来像这样： 16 | 17 | ![Istio工作流程](http://ww1.sinaimg.cn/large/7cebfec5gy1fu027jprkxj20r70a3dg4.jpg) 18 | 19 | 这和传统的nginx ingress有很大的不同，传统的nginx ingress使用iptables将流量转发到对应的pod上，如下图： 20 | 21 | ![nginx ingress workflow](http://ww1.sinaimg.cn/large/7cebfec5gy1fu028ondrgj20pe08vwen.jpg) 22 | 23 | 那么主要的区别是什么呢？那个被称为istio-proxy的sidecar容器会拦截流量，我对它拦截流量的方式特别感兴趣。 24 | 25 | 当你看到以下内容： 26 | 27 | ![](http://ww1.sinaimg.cn/large/7cebfec5gy1fu0291fi0xj20rs05d0tb.jpg) 28 | 29 | 这意味着在内核网络命名空间中，这个容器需要使用特权模式和设置 NET\_ADMIN 属性，这个非常重要。当你使用了`IP_TRANSPARENT` 这个 SOCK 选项或者管理iptables规则时，它不会作用于pod所在的主机而是作用于这个pod。 30 | 31 | 因此，当你在pod中使用nginx监听到80端口上，并使用istioctl注入一个sidecar容器时，在pod中的iptables规则将会是如下这样的(注意，你需要启用特权模式：`docker exec --privileged -it 75375f8d4c98 bash`： 32 | 33 | ```bash 34 | root@nginx-847679bd76-mj4sw:~# iptables -t nat -S 35 | -P PREROUTING ACCEPT 36 | -P INPUT ACCEPT 37 | -P OUTPUT ACCEPT 38 | -P POSTROUTING ACCEPT 39 | -N ISTIO_INBOUND 40 | -N ISTIO_OUTPUT 41 | -N ISTIO_REDIRECT 42 | -A PREROUTING -p tcpx -j ISTIO_INBOUND 43 | -A OUTPUT -p tcp -j ISTIO_OUTPUT 44 | -A ISTIO_INBOUND -p tcp -m tcp --dport 80 -j ISTIO_REDIRECT 45 | -A ISTIO_OUTPUT ! -d 127.0.0.1/32 -o lo -j ISTIO_REDIRECT 46 | -A ISTIO_OUTPUT -m owner --uid-owner 1337 -j RETURN 47 | -A ISTIO_OUTPUT -m owner --gid-owner 1337 -j RETURN 48 | -A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN 49 | -A ISTIO_OUTPUT -j ISTIO_REDIRECT 50 | -A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001 51 | ``` 52 | 53 | 可以很清晰的看到，iptables规则中将所有传入80端口的流量重定向到15001端口，这是istio-proxy绑定的端口，envoy会对流量进行处理并再次转发到80端口。 54 | 55 | netstat命令的显示结果如下： 56 | 57 | ![netstat](http://ww1.sinaimg.cn/large/7cebfec5gy1fu029d86bwj20om03rad8.jpg) 58 | 59 | tcpdump命令的显示结果如下： 60 | 61 | ![tcpdump](http://ww1.sinaimg.cn/large/7cebfec5gy1fu029nyzzpj20k002pwg5.jpg) 62 | 63 | 所有最初到80端口的流量会被重定向到本地的15001端口，在那个端口上运行的是envoy服务，下一步envoy会将流量发送到nginx。这就是为什么我们会看到两个HEAD请求，其中一个是被发送到envoy，另一个是被发送到nginx。 64 | 65 | 之后我会介绍如何设置所有的ingress元素。 -------------------------------------------------------------------------------- /2018/07/sidecar-design-pattern-in-your-microservices-ecosystem/index.md: -------------------------------------------------------------------------------- 1 | # 微服务生态中的 Sidecar 设计模式 2 | > 原文链接：https://dotnetvibes.com/2018/07/23/sidecar-design-pattern-in-your-microservices-ecosystem/ 3 | > 4 | > 作者：[SAMIR BEHARA](https://dotnetvibes.com/author/samirbehara/) 5 | > 6 | > 译者：[李昕阳](https://darrenxyli.com/) 7 | > 8 | > 审校：[宋净超](https://jimmysong.io) 9 | 10 | Sidecar 设计模式已经越来越受欢迎，并在社区内得到更广泛的采用。 构建具有高度可扩展性、弹性、安全性和可观察性的微服务架构具有挑战性。**Service Mesh 架构**的发展已经改变了游戏规则。它降低了与微服务架构相关的复杂性，并提供了许多功能，如负载平衡、服务发现、流量管理、熔断、遥测、故障注入等。 11 | 12 | 阅读我之前的博客能够了解 Service Mesh 的概念，为什么云原生应用需要它以及它受欢迎的原因——[服务网格架构的兴起](https://dotnetvibes.com/2018/07/02/the-rise-of-service-mesh-architecture/)。 13 | 14 | ## 什么是 Sidecar 模式 15 | 将应用程序的功能划分为单独的进程可以被视为 **Sidecar 模式**。Sidecar 设计模式允许你为应用程序添加许多功能，而无需额外第三方组件的配置和代码。 16 | 17 | 就如 Sidecar 连接着摩托车一样，类似地在软件架构中， Sidecar 应用是连接到父应用并且为其扩展或者增强功能。Sidecar 应用与主应用程序松散耦合。 18 | 19 | 让我用一个例子解释一下。想象一下假如你有6个微服务相互通信以确定一个包裹的成本。 20 | 21 | 每个微服务都需要具有可观察性、监控、日志记录、配置、断路器等功能。所有这些功能都是根据一些行业标准的第三方库在每个微服务中实现的。 22 | 23 | 但再想一想，这不是多余吗？它不会增加应用程序的整体复杂性吗？如果你的应用程序是用不同的语言编写时会发生什么——如何合并那些特定用于 .Net、Java、Python 等语言的第三方库。 24 | 25 | ## 使用 Sidecar 模式的优势 26 | - 通过抽象出与功能相关的共同基础设施到一个不同层降低了微服务代码的复杂度。 27 | - 因为你不再需要编写相同的第三方组件配置文件和代码，所以能够降低微服务架构中的代码重复度。 28 | - 降低应用程序代码和底层平台的耦合度。 29 | 30 | ## Sidecar 模式是如何工作的 31 | 服务网格层可以存在于与应用程序一起运行的 Sidecar 容器中。 每个应用程序旁边都附有相同 Sidecar 的副本。 32 | 33 | 来自单个服务的所有传入和传出网络流量都流经 Sidecar 代理。 因此，Sidecar 能够管理微服务之间的流量，收集遥测数据并实施相关策略。从某种意义上说，该服务不了解整个网络，只知道附加的 Sidecar 代理。这实际上就是 Sidecar 模式如何工作的本质——将网络依赖性抽象为 Sidecar。 34 | 35 | ![](https://ws1.sinaimg.cn/large/855e972fly1ftphar3kl3j210c0imgom.jpg) 36 | 37 | 在服务网格中有数据平面和控制平面的概念： 38 | 39 | - **数据平面**的职责是处理网格内部服务之间的通信，并负责服务发现、负载均衡、流量管理、健康检查等功能。 40 | - **控制平面**的职责是管理和配置 Sidecar 代理以实施策略并收集遥测。 41 | 42 | 在 Kubernetes 和 Istio 世界中，你可以将 Sidecar 注入 Pod 内。**Istio** 使用带有 **Envoy** 的 Sidecar 模型作为代理。 43 | 44 | **来自 Lyft 的 Envoy** 是为云原生应用程序设计的最流行的开源代理。Envoy 依附着每项服务运行，并以平台无关的方式提供必要的功能。所有的服务流量都通过 Envoy 代理流动。 45 | 46 | [https://www.envoyproxy.io](https://www.envoyproxy.io) 47 | 48 | ![](https://ws1.sinaimg.cn/large/855e972fly1ftphh5l8plj210n06taau.jpg) 49 | 50 | 从单体服务到微服务的转变使组织能够独立且大规模地部署应用程序。 在 Container 和 Kubernetes 世界中，Sidecar 设计模式更适合。Sidecar 从应用程序中抽象出了复杂性，并处理服务发现、流量管理、负载均衡、断路器等功能。 51 | 52 | 在此处了解有关 Sidecar 模式的更多信息： 53 | 54 | [https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar](https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar) -------------------------------------------------------------------------------- /2018/08/enabling-the-financial-services-shift-to-microservices/index.md: -------------------------------------------------------------------------------- 1 | # 金融服务正向微服务转型 2 | 3 | > 原文地址： 4 | > 5 | > 文中提到的调研报告: https://www.pwc.com/jg/en/publications/pwc-global-fintech-report-17.3.17-final.pdf 6 | > 7 | > 作者：[Zach Jory](https://aspenmesh.io) 8 | > 9 | > 译者：[甄中元](https://github.com/meua) 10 | > 11 | > 校对：[宋净超](http://jimmysong.io) 12 | 13 | ![](https://aspenmesh.io/wp-content/uploads/2018/07/Screen-Shot-2018-07-31-at-10.31.31-AM-1-768x327.png) 14 | 15 | 金融服务公司通常都拥有沉重的历史包袱，当然对于想要进入这个行业的新秀来说也算是商业壁垒，因为他们很难突破低利润和严苛的监管规则。曾占主导地位的大型金融企业的市场份额正面临着比起小巧、灵活的小金融科技公司的蚕食。这些小科技公司技术嗅觉灵敏、专业、注重客户用户体验。为了保持良好的竞争优势，金融服务公司都计划将自己原有的繁杂的技术架构向更具适应性的方向转变。最近对金融机构的一项调查发现大约85％的人认为他们的核心技术过于僵化和缓慢。因此，预计在未来五年内约有80％的金融机构打算替换其核心银行系统架构。 16 | 17 | 金融新法则旨在解决新的数字支付问题。例如在欧洲的PSD2（支付服务指令法则），要求银行采用新的运营方式和交付方式。像PSD2这样的变化旨在将银行业带入开放的API共享经济，通过开放标准推动互操作性和集成。要成为数据开放、无缝集成、API共享的世界一流金融科技需要借助微服务的力量。 18 | 19 | ### 微服务为金融服务提供了三个关键优势指标 20 | 21 | **增加安全性** 22 | 现代金融科技发展过程中给此前已建立的安全基础设施带来挑战。如数字钱包、智能机器人咨询服务和区块链等要求建立新的安全机制。恰恰微服务遵循这些要求正在构建基于最佳实践的独立身份识别服务。 23 | 24 | **快速交付** 25 | 快速将新功能推向市场是金融科技在市场上赢得头筹的基石，微服务使得不同应用开发团队独立交付满足新客户需求的功能更易于实现，微服务也具有很强的扩展性去满足更多用户和交易。 26 | 27 | **无缝集成** 28 | 金融科技在集成层面要求一组功能完备用于内部和外部不同服务间通信的服务接口。在大型单体应用中接口层由于改变难以管理而臭名昭著。而微服务利用隔离性、扩展性、弹性等众多特性使得接口更易于管理和更加安全。 29 | 30 | ### 服务网格使得繁杂的微服务管理易于实现 31 | 32 | 面对快速变化的客户、业务和监管要求，微服务帮助金融科技快速响应变化，但这不是轻而易举的，在转向微服务期间，公司需要承担增加的运营开销。而服务网格等技术恰可以帮助管理微服务。服务网格提供围绕可观测性、安全性、可控性一系列功能对于大规模管理微服务至关重要。 33 | 34 | 以前存在的解决方案（如DNS和配置管理）提供了例如服务发现等一些功能，但并没有提供快速重试、负载均衡、跟踪和运行状况监控的能力。管理微服务的老方法要求你在每次出现问题时拼凑出几种不同的解决方案，但是服务网格将它们打包起来使其更易于使用。虽然可以通过单个工具和流程完成服务网络管理的某些功能，但这是手动且耗时的。 35 | 36 | 随着初创金融科技公司的竞争，以及客户期望的不断增长，成熟的金融服务公司必须改变他们提供产品和与客户开展业务的方式。在交付层面老系统交付很难满足这些要求，金融服务公司需要一套灵活、适应性强、可扩展性高、可靠且强大的软件架构。微服务使其成为可能，而服务网络正好满足了微服务大规模管理的需求。 37 | -------------------------------------------------------------------------------- /2018/08/google-istio-bigger-kubernetes-serverless/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | 原文地址： 3 | 作者：[Cilium](https://cilium.io) 4 | 译者：[navy](https://github.com/meua) 5 | 审校：[宋净超](http://jimmysong.io) 6 | --- 7 | 8 | # Google加持Istio—这可能比Kubernetes和Serverless产生更大影响力 9 | 10 | Google Cloud采用了Istio服务网格技术来管理微服务，这可能比Kubernetes和无服务器产生更大的影响。 11 | 12 | 随着现代数字计算基础设施的不断发展，新的自动化层加速了创新和提升了适应性。一旦实现容器化微服务几秒之内部署一个新功能成为可能。那么Kubernetes和类似工具的出现增加了一层业务流程，以便大规模协调容器部署。在基础设施中一个功能很容易抽象成为一个满足需求的serverless模型。现在，正在形成一个称为“service mesh”的新层，以便在所有这些功能中添加服务间治理、管理和通信功能。8月1号一个名为Istio的service mesh的新开源框架1.0版本发布生产版本，像之前的Kubernetes一样，由谷歌以及IBM支持。 13 | 14 | ## 比Kubernetes更有价值 15 | 16 | 您可能没有听说过Istio，但如果您进行任何形式的敏捷数字开发或运维工作，您很快就会知道Istio。 Google云计算CTO（UrsHölzle）上周告诉我，他预计service mesh将会被普遍采用：“我希望看到的是，在两年后90％的Kubernetes用户将会使用Istio。Istio与Kubernetes提供的产品非常吻合，几乎感觉就像Kubernetes的下一次迭代。这是由同一个团队完成的，Istio和Kubernetes的功能能够很好的互补。” 17 | 18 | Hölzle没有明确地说Istio一定会比Kubernetes更大，但他非常确信Istio会和Kubernetes具有一样大的应用前景，甚至超过Kubernetes。 19 | 20 | ## Istio、Kubernetes和Serverless 21 | 22 | 在某种程度上，Hölzle的信心源于谷歌决定将Istio标准化为其云服务平台（[Cloud Services Platform ](https://cloudplatform.googleblog.com/2018/07/cloud-services-platform-bringing-the-best-of-the-cloud-to-you.html)）的管理层，该服务于上周在Cloud Next会议上宣布。这与上周推出的另外两个新项目同时启动。一个是[Knative](https://www.infoq.com/news/2018/07/knative-kubernetes-serverless)—一个基于Kubernetes的开源框架，用于构建、部署和管理serverless工作负载，正如Kurt Marko本周早些时候在他的[Cloud Next文章](https://diginomica.com/2018/07/30/google-cloud-platform-removes-barriers-between-it-business/)中所解释的那样，“Knative不仅仅是一个serverless的容器包装器，而是一个容器化应用的开发框架“。另一个是谷歌GKE（Google Kubernetes Engine）私有云版本，是云供应商的容器管理工具。结合Istio的管理层，这实际上意味着组织可以从私有云到公有云使用CSP管理整个IT基础架构中的容器生态系统和serverless。 23 | 24 | Istio是Google、IBM和Lyft共同努力在一年多前推出的一项开放式技术框架，用于连接、保护、管理和监控云的服务网络。这三家公司都贡献了他们单独开发的现有技术。 25 | 26 | ## 减轻企业上云难度 27 | 28 | Hölzle认为，Istio将加速企业采用公有云，因为它可以在私有化部署和云之间实现更高的同质化：“公司决定将所有内容（包括他们不想重写的旧代码）移至Istio，去包装旧代码而不去重写它这是非常合理的。我们相信GKE私有化部署将带领更多客户深入云技术。因为它与现代云思维非常融合，它保留了它们的地址以及何时何地去迁移的选择机会。你可以在任何你喜欢的云提供商之间自由迁移，且使你上云之路更加平稳。一旦人们熟悉了Kubernetes和Istio的管理和编排方式，上云就不会变得可怕了。” 29 | 30 | Hölzle认为BigQuery这样的云原生功能将继续为它们提供最终结果。与此同时，它依靠思科等合作伙伴提供GKE和Knative的私有化版本，而不是成为该技术本身的直销商。 31 | 32 | ## 合作伙伴和开发者 33 | 34 | 合作伙伴还将发现Istio有助于他们从硬件产品转向安全等领域的软件和服务云转型。Hölzle认为：“许多合作伙伴正在转向销售软件和销售服务，这是进入该领域的理想切入点。如果您是正在使用Istio的服务安全提供商，将服务从本地迁移到云将不受影响，只有位置发生变化了。在当前模型中，如果您是本地提供商，所有API都不同，所有需要回答的问题都是新的，您可能会失去现任状态，因为您无法轻松移植到云端”。 35 | 36 | 开发人员也需要得到说服。但谷歌开发者关系部副总裁亚当·塞利格曼认为，他对Istio为他们开放的东西感到很兴奋：“使用Istio不需要大量的重新编程。现有的应用程序、功能和服务可以使用Istio进行流量路由，并立即看到当前各维度的运行状态。你将没有使用Istio的应用程序加入Istio，你会获得以前无法获得的所有可见性。我认为这会刺激很多开发人员，加速Istio被采用的速度。我认为开发人员需要接受SLO（服务级别目标）监控、金丝雀部署、流量控制、A/B测试甚至多变量测试等技术培训。” 37 | 38 | ## 我的见解 39 | 40 | Istio不是唯一实现service mesh的技术框架，linkerd—由Buoyant支持的开源项目，早于Istio，已经投入生产。但谷歌、IBM和思科等重量级合作伙伴给Istio带来了比Bouyant对linkerd更大的支持。最后，重要的是服务网格的原则而不是具体的实现。一直存在着反对过度使用微服务的争论，因为你拥有的自主服务越多，管理它们就越复杂。在Istio的支持下，Google正在验证解决这个棘手问题的微服务架构，以便所有这些松散耦合的端点可以合理地协调以产生有用的业务成果。这似乎应该是云计算发展中非常重要的进展。 -------------------------------------------------------------------------------- /2018/08/hashicorp-extends-consul-to-support-other-service-meshes/index.md: -------------------------------------------------------------------------------- 1 | > 原文地址： 2 | > 3 | > 作者：[Alex Handy](https://thenewstack.io/author/alex-handy/) 4 | > 5 | > 译者：[甄中元](https://github.com/meua) 6 | > 7 | > 校对：[宋净超](http://jimmysong.io) 8 | # HashiCorp扩展Consul以支持其他服务网格 9 | 10 | ![](https://storage.googleapis.com/cdn.thenewstack.io/media/2018/07/c7eb09dd-network-3286024_1280-1024x573.jpg) 11 | 服务网络之战正在激烈进行中，自从该模式成为一种在基于微服务之间可靠路由流量的方式以来。它已经扩展成更加广泛的生态系统，虽然该术语起源于[HAProxy](http://www.haproxy.org/)等工具，包含如[Lyft](https://www.lyft.com/)、[Envoy](https://www.envoyproxy.io/)和可以实际路由和平衡任何涉及数据包[NGINX](https://www.nginx.com/)的web服务。 12 | 13 | [Armon Dadgar](https://www.linkedin.com/in/armon-dadgar/)，HashiCorp的CTO，提供更友好的解决方案：为什么不全部使用它们？在[HashiDays](https://www.hashidays.com/)该公司上周在阿姆斯特丹召开的开发者大会上，Dadgar和HashiCorp的技术团队公布了其Consul注册和服务发现产品的最新更新。 14 | 15 | Consul现在能够理解云环境中的服务网格层，同时在它所跟踪的服务之间维护一个安全的网络。[Consul Connect](https://www.consul.io/intro/getting-started/connect.html)的新功能允许对各个服务进行分段，以实现对它们的访问控制。这意味着可以锁定服务，只能访问其他特定的经过验证的服务。 16 | 17 | Dadgar说：“我们正在将Consul变成一个成熟的服务网格。现在我们可以使用Consul，“Web服务可以与数据库通信，并且该服务可以与数据库通信，Consul设置服务拓扑图并有效地分发将其缓存在所有节点上。Consul提供了一个生成证书、签名、管理证书的工作流程。贯穿整个生命周期”。 18 | 19 | Consul Connect包含许多先前版本平台的附加功能。它现在包括基于证书的服务标识和服务之间的加密通信。 20 | 21 | Dadgar表示，HashiCorp的团队正试图找到一种方法来保护像公有云或多云环境这样的不受信任的网络服务之间的流量。最后，他们决定从世界上最大的不受信任的环境中获取线索，因此，他们启用了TLS作为其基于Consul的服务网格功能的加密层。 22 | 23 | Consul现在解决的另一个挑战是配置问题。代理、负载均衡和Web应用程序防火墙等安全设备，所有这些都在服务网络和基于云的环境中扮演者重要角色，随着网络抖动、云端迁移，保持所有配置正确可能是一项挑战。 24 | 25 | 为解决此问题，Consul接管服务网格中每个工具节点的配置管理职责。Dadgar将Consul比作服务网格的控制平面，而其他系统则执行数据平面的任务，管理控制流和信息路由。 26 | 27 | Dadgar说：“我们最终会做一个合理的数据平面。目标是带你入门。然后我可以引入Envoy、HAProxy、NGINX或其他可能的服务并插入其中。在数据平面层，我可以自由选择适用于我的系统的东西，但Consul是最重要的控制平面。使任何现有的应用程序，从大型机到裸机，我们可以采用细粒度的服务间通信模型使它们适合这种现代服务网格模型。在我们构建多云环境时，我们没有遇到`如何将我的VLAN带到所有这些环境？`的问题。”。 28 | 29 | Dadgar指出，现在似乎在整个服务网格中控制平面缺失某些功能。“Envoy是一个很棒的数据平面。作为代理，它的功能超级丰富，但它不附带内置的控制平面。我们已经看到许多项目将控制平面与它拼凑在一起，但我们的观点是我们无法仅使用数据平面来解决分割问题。因此它变得脱节了。您需要将这些不同的信息放在一起，以便我可以围绕它进行服务发现。例如，控制平面必须知道数据库的位置。对我们来说，解决发现和配置这是很自然的事情”。 30 | 31 | 接着他进一步介绍了正在探索的与老数据中心类似的多云平台，针对云的旧工具和端点被重新设计。防火墙就是其中一个。 32 | 33 | Dadgar说：“我们期待的重大事情是，如何重新思考更广泛的网络环境。HashiCorp作为一个整体，从VMWare中的ITIL交付过渡到多云配置，我们认为网络层、配置层......它们都经历了相同的过渡。当我们认为网络正在经历从集中式硬件设备驱动到基于分布式软件的快速转变中。所有传统的网络设备都将经历这一过程。Consul connect贯穿这些的防火墙，其他组件同样如此。” 34 | -------------------------------------------------------------------------------- /2018/08/istio-aims-to-be-the-mesh-plumbing-for-containerized-microservices/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | 原文链接：https://www.nextplatform.com/2018/08/15/istio-aims-to-be-the-mesh-plumbing-for-containerized-microservices/ 3 | 发布时间：2018年8月15日 4 | 作者：Daniel Robinson 5 | 译者：moxi 6 | --- 7 | ![](https://ws2.sinaimg.cn/large/0069RVTdly1fupfdbzbm4j30iu0altbn.jpg) 8 | ## ISTIO目标是成为容器化微服务的网状管道 9 | 10 | 在精彩的软件容器世界中，原本早已解决的问题又有新的解决方案出现，给人有种恍惚的感觉。在许多情况下这些问题很久以前就得到了解决，但现代云原生架构的出现，推动部署更大规模的应用程序，这就需要新的工具和方法来管理这些服务。 11 | 12 | 微服务就是一个很好的例子。在此模型下，典型的应用程序或服务将被分解为可独立部署的功能模块，这些模块可以彼此分开扩展和维护，并且链接在一起以提供整个应用程序或服务的全部功能。 13 | 14 | 15 | 在使用容器开发微服务时，后者可能是比较棘手的部分。当所有组件可能分布在服务器节点集群中，并且它们的实例不断上线并被更新的版本替换时，如何将它们连接起来？在面向服务的体系结构（SOA）中，微服务可以被看作是[进化的继承者](https://www.nextplatform.com/2017/01/03/from-monolith-to-microservices/)，这种任务类似于企业服务总线（ESB）所处理的任务。因此，我们需要的是ESB的云原生版本。 16 | 17 | 这是一个相对较新的开源项目[Istio](https://istio.io/)旨在填补的工作。它被正式描述为服务网格，因为它的一部分与基础设施一起分布在它管理的容器旁边，并且它开始着手满足服务发现、负载均衡、消息路由、遥测和监控的要求，当然还有安全。 18 | 19 | Istio源自IBM和谷歌之间的合作，实际上包含了一些现有的组件，特别是由打车服务公司Lyft开发的组件。它以某种形式存在至少一年，但最终在7月底达到1.0版的里程碑，这意味着它现在终于被认为足够成熟，可以作为生产基础设施的一部分来运行。 20 | 21 | IBM研究员兼IBM云计算首席技术官Jason McGee告诉The Next Platform，云原生生态系统已基本确定容器作为核心打包和运行时构造，而Kubernetes则作为管理容器的编排系统。但McGee解释说，还有第三块谜题还在空中，Istio旨在满足这一要求。 22 | 23 | “如何管理在容器平台上运行的应用程序或服务之间的交互？”McGee问道。 “如果您正在构建微服务，或者您有一组应用程序，那么应用程序之间的通信会出现很多有趣的问题。您如何了解到底是那些服务在交互，性能以及如何收集应用程序之间通信的数据，如何保护控制哪些服务可以相互通信的通信，以及如何确保应用程序的安全，特别是在我们今天使用的更动态或分布式架构情况下，您可能在公有云或私有云上同时有组件。“ 24 | 25 | McGee说他几年前在IBM的团队已经开始研究这个问题了，当时他遇到了谷歌的同行并发现他们正走在同一条道路上，**但IBM主要关注流量路由、版本控制和A/B测试方面，Google专注于安全和遥测。两者决定合并各自的努力成果，这样就诞生了Istio。** 26 | 27 | Istio由以下组件组成： 28 | - Envoy，被描述为sidecar代理，因为它作为代理部署在每个微服务实例旁边。 29 | - Mixer，它是一个核心组件，用于通过Envoy代理执行策略，并从中收集遥测指标。 30 | - Pilot负责配置代理； 31 | - Citadel是负责颁发证书的中心化组件，也有自己的每个节点代理。 32 | 33 | Envoy是由Lyft开发的组件，被McGee描述为“非常小的足迹，第4到第7层智能路由器”，它捕获与其配对的微服务的所有传入和传出流量、控制流量、应用策略和收集遥测信息。 Pilot是IBM提供的主要组件，作为部署在基础架构中的所有Envoy代理的控制平面。 34 | 35 | “如果你想象在一个服务网格中，你可能有一百个微服务，如果每个服务都有多个实例，你可能有数百或数千个智能路由，你需要一种方法对它们进行编程，所以Istio引入了这个称为Pilot的东西。可以把它想象成程序员，所有这些路由器的控制平面。所以你有一个地方可以来编程这个服务网络，然后围绕数据收集进行遥测，围绕安全的证书管理，但从根本上你有这个智能路由层和这个控制平面来管理它， “McGee解释道。 36 | 37 | Istio还有自己的API，允许用户将其插入现有的后端系统，例如用于日志记录和遥测。 38 | 39 | 根据谷歌的说法，Istio的监控功能使用户能够测量服务之间的实际流量，例如每秒请求数，错误率和延迟，还可以生成依赖关系图，以便用户可以看到服务如何相互影响。 40 | 41 | ![](https://ws3.sinaimg.cn/large/0069RVTdly1fupgnkp2owj30iu08rwfg.jpg) 42 | 43 | 通过Envoy sidecar代理，Istio还可以在每个服务调用时使用双向TLS身份验证（mTLS），加密并使用户能够在基础架构范围内对每个调用进行授权。 44 | 45 | Istio的目的是，消除开发人员需要担心的许多问题：实例之间的通信安全问题，控制哪个实例可以与哪些实例进行通信以及提供执行诸如金丝雀部署之类的操作，如果是特定微服务代码的新版本发布了，那么只有一个实例的子集会被更新，直到您满意新代码的运行可靠为止 46 | 47 | 应该注意的是，其他服务网状平台已经存在，例如开源端的Linkerd或Conduit，而微软有一项服务，被称为[Azure Service Fabric Mesh](https://docs.microsoft.com/en-us/azure/service-fabric-mesh/service-fabric-mesh-overview)，目前作为其云平台的技术预览。此外，服务网格表示网络管道上方的抽象层，因此假设已经为每个容器实例配置了网络接口，IP地址和其他网络属性。这通常意味着，无论何时创建新的容器实例，部署微服务还将需要一个单独的工具来自动化网络配置。 48 | 49 | 然而，IBM希望Istio将成为云原生工具包的标准组成部分，[正如Kubernetes所发生的那样](https://www.nextplatform.com/2018/07/17/when-does-kubernetes-become-invisible-and-ubiquitous/)，Kubernetes是基于Borg和Omega技术的，而这些技术是为谷歌自己的内部集群和其上运行的容器层而开发的。 50 | 51 | “从社区的角度来看，我的期望是Istio将成为架构的默认部分，就像容器和Kubernetes已经成为云原生架构的默认部分一样，”McGee说。为此，IBM希望将Istio与其公有云提供的托管Kubernetes服务以及其内部部署的IBM Cloud Private堆栈集成在一起。 52 | 53 | “所以，你今天可以运行Istio，我们支持今天在这两个平台上运行Istio，但期望应该是在不久的将来，我们将内置Istio，所以每当你使用我们的平台时， Istio组件集成在里面了，您可以利用它，并且不必负责部署和管理Istio本身，只需在您的应用程序中使用它即可，“McGee说。 54 | 55 | 谷歌已经添加了Istio支持，尽管它只是将其标记为alpha版本，作为托管服务的一部分，该服务在其云平台上的客户的Google Kubernetes Engine（GKE）集群中自动安装和维护。 56 | 57 | Istio也获得了业内其他公司的支持，尤其是Red Hat，几年前Red Hat以Docker容器和Kubernetes为基础，重新设计了OpenShift应用程序平台。 58 | 59 | Red Hat的Istio产品经理人称“红胡子”的Brian Harrington表示Red Hat打算将服务网格集成到OpenShift中，但Red Hat希望在提交之前能够看到改进的一些粗略的地方，例如多租户支持。 60 | 61 | “Istio现在的目标是他们所谓的软多租户，也就是说，我们希望在组织内部可用，以便该组织内的两个不同的团队可以使用并信任它，前提是团队内只要没有一个人的行为过于恶意，大家都没有准备去影响其他人的服务。通过我们运行OpenShift Online的方式，我们让客户运行我们从未看过的代码，并且我们必须最终安排这两个客户并存，这是一个非常不同的多租户挑战，“Harrington解释道。 62 | 63 | “我们需要对这个多租户功能有更高的信心;我们需要对性能和稳定性有更高的信心。在这些方面还没有看到有完美的解决方案，但是在进行规模测试和自动化一些回归测试时，我们看到了一些我们认为可以提供大量价值的地方，我们还在社区层面贡献了一个名为[Kiali](http://www.kiali.io/)的项目，给出了Istio操作过程的可视化，这只是我们产品的一部分，“他补充道。 64 | 65 | 换句话说， Istio只是为那些希望构建云原生应用程序基础架构的用户提供的添加到选项菜单中的另一个开源工具。 像Red Hat这样的供应商将把它融入他们经过测试和支持的企业平台产品中，比如OpenShift，而其他供应商则希望自己混合搭配并构建它。 66 | -------------------------------------------------------------------------------- /2018/08/istio-service-mesh-tech-boosts-kubernetes-work-with-trade-offs/index.md: -------------------------------------------------------------------------------- 1 | # 运行在Kubernetes上的Istio服务网格之利弊分析 2 | 3 | > 原文链接：https://searchitoperations.techtarget.com/tip/Istio-service-mesh-tech-boosts-Kubernetes-work-with-trade-offs 4 | > 5 | > 作者：[Alan R. Earls](https://www.techtarget.com/contributor/Alan-R-Earls) 6 | > 7 | > 译者：[殷龙飞](https://github.com/loverto) 8 | > 9 | > 审校：[宋净超](https://jimmysong.io) 10 | 11 | 为什么 IT 团队不可以使用一种工具，使开发人员能够专注于编写应用程序代码，使管理员可以以专注于 IT 资源的操作？尽管如此，Istio 确实需要研究利弊。 12 | 13 | Kubernetes 是一个开源容器编排系统，它提供了管理和扩展容器化应用程序的强大功能，但有些事情它不能很好地完成。而 Istio 增加了额外的支持，它可以管理微服务之间的流量。 14 | 15 | 16 | Istio 服务网格项目是平台无关的，协作和开源的，由 IBM、Google 和 Lyft（基于应用程序的传输服务）开发。[它使用代理 sidercar 模型](https://searchmicroservices.techtarget.com/news/450419875/IBM-Google-Lyft-launch-Istio-open-source-microservices-platform)在云平台上连接、保护、管理和监控微服务网络。Istio 明确[定义了基础架构的作用](https://searchitoperations.techtarget.com/feature/Service-mesh-architecture-radicalizes-container-networking)，与运行在其上的软件分离。 17 | 18 | ### 集成Istio的利弊 19 | 20 | 编排工具 [Kubernetes](https://searchitoperations.techtarget.com/definition/Google-Kubernetes) 与 Istio 的整合，可以让开发人员和 IT 管理员在应用程序容器化这一共同目标上一起努力，IT 管理软件提供商 SolarWinds 的首席软件架构师 Karlo Zatylny 表示: “软件开发人员将注意力集中在编写能够创造最大商业价值的代码上”。他们不需要考虑[部署因素](https://searchitoperations.techtarget.com/ehandbook/How-container-deployment-changes-the-capacity-management-equation)，例如支持容器的 VM 和物理环境。 21 | 22 | Zatylny 说：通过 Istio，IT 管理员可以专注于计算资源和网络资源，而不是处理特定的硬件和虚拟分配。部署的基于微服务的应用程序在消耗可用资源方面变得更有效率，而不是在过度使用未充分利用基础架构的某些部分。Istio 还使用配置驱动的通信架构，这提高速度缩短了开发周期，因此开发人员可以在业务需求变化时轻松地对软件重构。 23 | 24 | 尽管代码复用和其他设计都极大的降低了复杂度，但 Istio 服务网格设计带来了复杂性和额外的管理开销。 25 | 26 | Istio 在上行和下游提供负载均衡、鉴权、可见性和运行状况检查，使管理员能够查找、连接和路由各个部署部分。IDC 分析师 Brad Casemore 表示，它将网络应用于[开放系统互连模型（OSI）](https://searchnetworking.techtarget.com/definition/OSI)第7层的微服务交付环境，而不是IP的第3层或第2层的以太网。 27 | 28 | Red Hat 产品管理高级主管 Rich Sharples 说，在 Istio 服务网格中控制和数据平面之间的分割概念可能会使用户感到困惑，但实际上相当简单。数据平面使用简单的代理架构来调解服务网格中每个服务的所有入站和出站流量。控制平面处理服务注册和发现、认证、访问控制、证书管理（即签名、发布和撤销）和服务网格配置，以及来自服务和服务代理的遥测数据。 29 | 30 | 服务网络可在 [API](https://searchmicroservices.techtarget.com/definition/application-program-interface-API) 后面实现安全、可靠的服务器到服务器通信。“当你构建微服务时，你通常会公开一个 API，它会公开功能，然后通过一系列服务来实现”， Gartner 分析师 Anne Thomas 表示。因为容器是短暂的，这意味着它们不会保留会话信息，管理员必须定期重新连接它们，并且它们需要安全授权功能，以确保部署的服务器到服务器通信受到保护和运行。 31 | 32 | Istio 的服务网格定位服务，确保通信的健壮性，并在连接失败时执行重试或找到必要服务的另一个实例并建立连接。Thomas 说：服务网格还可以实现隔板和断路器。隔板隔离应用程序的各个部分，以确保任何给定的服务故障不会影响任何其他服务。断路器是一种监控组件，具有用于[外部微服务通信](https://medium.com/microservices-in-practice/microservices-in-practice-7a3e85b6624c)的编程故障阈值；断路器杀死故障服务以调节资源消耗并请求响应时间。 33 | 34 | [东西向通信能力](https://searchsdn.techtarget.com/definition/east-west-traffic)是微服务的另一个关键需求。将客户端连接到服务的API网关是南北向通信; 这通常是足够的，但是为了实现其背后具有附加服务的微服务，服务网络创建东西向通信，即IT环境内的通信。Istio是为这种通信途径而构建的。 35 | 36 | Istio 有一些缺点，因为它提供了一个标准的多语言运行时服务网格，可以在给定的云平台上运行，但一如既往，我们需要权衡利弊。虽然 Istio 使开发人员能够在不模糊应用逻辑的情况下生成智能微服务设计模式和最佳实践，但该功能具有性能和延迟影响，Sharples 说。Sharples 表示，Istio 的代理 sidecar 模型（用于调解流量的开源 Envoy边缘代理）——引入了额外的网络调用，可能会为高性能实时应用产生[不可接受的延迟](https://searchmicroservices.techtarget.com/tip/Microservices-challenges-include-latency-but-it-can-be-beat)。 37 | 38 | ### 如何采用 Istio 服务网格 39 | 40 | Istio 在测试版中，在发布时没有提供商业支持。Casemore 说，对于大多数组织来说，这仅是一个有用的 POC 项目，而且是那些具有冒险精神的人将它运行在非关键业务应用程序时。 41 | 42 | IDC 的分析师 Gary Chen 说：“这项技术适用于那些处于技术前沿的团队，但是他们必须非常自信才会采纳该技术”。 -------------------------------------------------------------------------------- /2018/08/tracing-services-with-istio/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | 原文链接：https://hackernoon.com/tracing-services-with-istio-e51d249da60c 3 | 发布时间：2018-07-25 4 | 译文链接：https://maiyang.me/post/2018-08-03-tracing-services-with-istio/ 5 | 作者：Jeronimo (Jerry) Garcia 6 | 译者：maiyang 7 | --- 8 | 9 | ## Istio 跟踪服务 10 | 11 | 超快速发布，当 Istio 将 envoy 容器使用 sidecar 的方式注入 pod 中后，每一个进出的请求都会附加一些 http 头信息，然后使用这些头信息用于跟踪。 12 | 13 | 这是 Istio 所拥有的 “sidecar 注入” 方法的众多好处之一，有点干扰，但到目前为止似乎工作得很好。 14 | 15 | 好了，你可以通过以下脚本来快速的部署 jaeger 和 zipkin ： 16 | 17 | [helm istio values](https://github.com/istio/istio/blob/master/install/kubernetes/helm/istio/values.yaml#L415) 18 | 19 | 如果你还没有启用它，然后如果你能在图表上看到一小块，你会发现如下参考： 20 | 21 | ![1_IeIAfZClvqJHvDkXTulDrg](https://ws4.sinaimg.cn/large/006tKfTcgy1ftw4urdnj6j30m10680sm.jpg) 22 | 23 | 它是 Mixer，不需要太多的深入，你可以看到 mixer 如何将统计数据传递给 zipkin，并记住 mixer 看到的一切。 24 | 25 | 因此，我们可以使用 port-forward（端口转发） 查看 jaeger 的监听： 26 | 27 | ```shell 28 | $ kubectl port-forward -n istio-system istio-tracing-754cdfd695-ngssw 29 | 16686:16686 30 | ``` 31 | 32 | 我们点击 [http://localhost:16686](http://localhost:16686) ，我们会找到 jaeger： 33 | 34 | ![1_5KEKom5j8tyagFVdSIGWlw](https://ws4.sinaimg.cn/large/006tKfTcgy1ftw4vl7uvjj30wx0kita2.jpg) 35 | 36 | 这对于跟踪和获得那些可能需要花费太长时间才能处理的服务的时候非常有趣，我人为的弄出些错误，它看起来像： 37 | 38 | ![1_gECzUb6Hh5QjxK0-ueYT8g](https://ws4.sinaimg.cn/large/006tKfTcgy1ftw4wduq16j318g0meq5w.jpg) 39 | 40 | 如果 `nginx pod` 会调用额外的服务，那么这里也应该显示，请记住所有入口/出口流量都是由你的 pod 中的 `envoy sidecar` 捕获的。 41 | -------------------------------------------------------------------------------- /2018/08/why-you-should-care-about-istio-gateways/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | 原文链接：https://thenewstack.io/why-you-should-care-about-istio-gateways/ 3 | 发布时间：2018-08-02 4 | 作者：Neeraj Poddar 5 | 译者：王帅俭 6 | 审校：宋净超 7 | --- 8 | 9 | ## 为什么你应该关心Istio gateway 10 | 11 | 如果您要拆分单体架构，使用Istio管理您的微服务的一个巨大优势是，它利用与传统负载均衡器和应用分发控制器类似的入口模型的配置。 12 | 13 | 在负载均衡器领域，虚拟IP和虚拟服务器一直被认为是使运营商能够以灵活和可扩展的方式配置入口流量的概念（[Lori Macvittie对此有一些相关的想法](https://devcentral.f5.com/articles/wils-virtual-server-versus-virtual-ip-address))。 14 | 15 | 在Istio中，[Gateway](https://istio.io/docs/reference/config/istio.networking.v1alpha3/#Gateway)控制网格边缘的服务暴露。Gateway允许用户指定L4-L6设置，如端口和TLS设置。对于Ingress流量的L7设置，Istio允许您将网关绑定到[VirtualServices](https://istio.io/docs/reference/config/istio.networking.v1alpha3/#VirtualService)。 16 | 17 | 这种分离使得管理流入到网格的流量变得容易，就像在传统负载均衡器中将虚拟IP绑定到虚拟服务器一样。这使得传统技术栈用户能够以无缝方式迁移到微服务。对于习惯于整体和边缘负载均衡器的团队来说，这是一种自然的进步，而不需要考虑全新的网络配置方式。 18 | 19 | 需要注意的一点是，在服务网格中路由流量和将外部流量引入网格不同。在网格中，您在正常流量中分辨异常的部分，因为只要在服务网格内，默认情况下Istio可以与（与Kubernetes兼容）所有应用通信。**如果您不希望与某些服务进行通信，则必须添加策略。** 20 | **反向代理（类似于传统的负载均衡器）获取进入网格的流量，您必须准确指定哪些流量允许进入网格。** 21 | 22 | 早期版本的Istio利用Kubernetes的[Ingress资源](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.11/#ingress-v1beta1-extensions)，但最近发布的Istio v1 alpha3 API利用Gateway提供更丰富的功能，因为Kubernetes Ingress已被证明不足以满足Istio应用程序的要求。Kubernetes Ingress API合并了L4-6和L7的规范，这使得拥有单独信任域（如SecOps和NetOps）的组织中的不同团队难以拥有Ingress流量管理。 23 | 24 | 此外，Ingress API的表现力不如Istio为Envoy提供的路由功能。在Kubernetes Ingress API中进行高级路由的唯一方法是为不同的入口控制器添加注解。组织内的单独关注点和信任域保证需要一种更有效的方式来管理入口，这些可以由Istio Gateway和VirtualServices来完成。 25 | 26 | 一旦流量进入网格，最好能够为VirtualServices提供分离的关注点，以便不同的团队可以管理其服务的流量路由。 L4-L6规范通常是SecOps或NetOps可能关注的内容。 L7规范是集群运营商或应用程序所有者最关心的问题。因此，正确分离关注点至关重要。 27 | 28 | 由于我们相信团队责任的力量，我们认为这是一项重要的能力。由于我们相信Istio的力量，我们正在Istio社区中提交[RFE](https://docs.google.com/document/d/17K0Tbp2Hv1RAkpFxVTIYPLQRuceyUnABtt0amd9ZVow/edit#heading=h.m6yvqjh71gxi)，这将有助于为网格内的流量管理启用所有权语义。 29 | 30 | 我们很高兴Istio已经发布[1.0版本](https://thenewstack.io/istio-1-0-come-for-traffic-routing-stay-for-distributed-tracing/)，并且很乐意继续为项目和社区做出贡献。 -------------------------------------------------------------------------------- /2018/09/api-management-and-service-mesh/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://itnext.io/api-management-and-service-mesh-e7f0e686090e 3 | translator: roganw 4 | reviewer: 5 | title: "API Management和Service Mesh" 6 | description: "本文分别介绍了API Management和Service Mesh，并简单分析了它们的共同点。" 7 | categories: "译文" 8 | tags: ["API Management","API Gateway","Service Mesh"] 9 | date: 2018-09-28 10 | --- 11 | 12 | # API管理和服务网格——为什么说服务网格无法替代API管理 13 | 首先声明，我在RedHat工作，确切得说，是在3scale团队开发3scale API管理解决方案。最近，在跟我们的客户讨论时有个问题被越来越多的提及：`使用了Istio之后，为什么还需要API管理？` 14 | 15 | 为了回答这个问题，我们首先要搞明白服务网格和API管理究竟是什么，剧透一下：3scale API Management和Istio可以共存。 16 | 17 | 让我们聚焦于3scale API Management和Istio Service Mesh（这两者是我比较了解的），我会尽量描述清楚这两个方案的目标是解决哪些问题。 18 | 19 | ## API Management解决方案是什么？ 20 | 21 | 我们先看一下Wikipedia的定义：`API管理的过程包括创建和发布Web API、执行调用策略、访问控制、订阅管理、收集和分析调用统计以及报告性能。` 22 | 23 | 这是一个清晰的定义。作为一家已经创建了一系列内部Service的公司，我现在希望通过向外部订阅者提供API的方式构建业务。当然，我会通过提供一些订阅计划来量化它，包括使用限制、范围，并且可以自动的给客户提供账单。 24 | 25 | 此外，外部开发者可以很容易地发现我提供的API，并使用他们的信用卡以自服务的方式注册订阅计划，而这一切，对我的API代码来说应该是透明的。 26 | 27 | ![API Management Platform](https://ws1.sinaimg.cn/large/006tNc79gy1fvpbzdautwj30m80cp412.jpg) 28 | 29 | 分析过这些需求之后，我们可以把它们归为以下几类： 30 | * 访问控制和安全：控制谁可以访问我的API，以及以何种方式访问。 31 | * API契约和流量限制：一位用户在一次订阅的情况下可以调用多少次请求。 32 | * 分析和报告：API运行情况怎么样？哪些方法被调用的最为频繁？有没有错误？API调用的趋势是什么？ 33 | * 开发者门户，文档：让开发者发现你的API并注册订阅计划。 34 | * 账单：提供发票并向开发者收取费用。 35 | 36 | API管理方案是如何做到这些的？这要得益于一个叫做API Gateway的组件。 37 | 38 | ![API Gateway](https://ws4.sinaimg.cn/large/006tNc79gy1fvpc2rrv5xj30lq097t90.jpg) 39 | 40 | 这是一个位于调用流程中间环节的组件，所有客户端请求都会经过它，它能够保护你的API端点，并通过与其他API Management组件通信来决定是否让一个用户访问的你的API。 41 | 42 | 它一般是通过对用户请求进行身份识别和流量控制来实现的。考虑下面这个场景： 43 | * 用户A订阅了`Basic Plan`。 44 | * `Basic Plan`定义了一些API操作（HTTP Method + HTTP path）的限制，例如：`Get /products`和`POST /shipments`。 45 | * 这些限制可以被定义成每秒/分钟/月等等。 46 | * `GET /Products`可以被限制成每分钟请求10次。 47 | 48 | 在这种情况下，当用户A想在1分钟内调用10次以上时，超出的请求就会因为流量控制而收到429状态码。或者身份验证没有通过，用户就会收到403（Forbidden）状态码。身份识别可以通过Oauth、请求参数或者header来提供。 49 | 50 | 流量控制是API Management的关键部分。这也是API Gateway针对最终用户执行业务规则的部分，流量控制可以实现非常复杂的场景，比如基于多条规则或客户端IP。API Management之所以强大，在于它可以满足复杂流量控制场景（业务规则）的能力。 51 | 52 | 因此，我可以大声地说：`API Management 不（仅仅）是流量限制。` 53 | 54 | ## Service Mesh是什么？ 55 | 56 | 前面我们讲了API，却没有提及Service、Application、Port、Connection、Retry等等，因为在API Management层，我们不需要关心这些。但是现在我们需要了。 57 | 58 | API的背后是什么？多个互相通信的Service，它们之间的交互组成了一个完整的API，每个Service可能由不同的编程语言实现，并且由同一个庞大组织内的不同地区的不同团队进行维护和操作。这听起来耳熟吗？对，微服务！ 59 | 60 | ![Microservice or connected dots](https://ws1.sinaimg.cn/large/006tNc79gy1fvpc2uooboj30lo0f1wek.jpg) 61 | 62 | 一个完整的API，由多个Service共同完成，这听起来很棒，但是随着越来越多的团队为新特性或新需求发布新的Service，日渐增长的架构运维复杂度问题就会暴露出来： 63 | * 如果Service之间的内部调用失败了会发生什么？ 64 | * 请求失败发生在哪里？ 65 | * 为什么这个API端点这么慢？哪个Service有问题？ 66 | * 这个Service真的容易出错，我们可以在出错的时候重试吗？ 67 | * 某人总是在每天的同一时刻大量请求这个Service，我们需要通过流量限制避免它。 68 | * 这个Service不可以访问到另一个Service...... 69 | 70 | 这些问题可以由Service Mesh解决，并归为以下类别： 71 | * 弹性：超时、重试、熔断、故障处理、负载均衡。 72 | * 流量限制：基于多个来源的基础设施流量限制。 73 | * 通信路由：根据path、host、header、cookie base、源Service...... 74 | * 可观测性：指标、日志、分布式追踪。 75 | * 安全：mTLS、RBAC...... 76 | 77 | 所有这些都是以对Application透明的方式执行的。 78 | 79 | 我们来看一下Istio是如何工作的： 80 | 81 | ![Istio Components diagram](https://ws4.sinaimg.cn/large/006tNc79gy1fvpc361862j30dc0ao74r.jpg) 82 | 83 | Istio使用`sidecar 容器`模式，通过在同一个Pod中运行一个新增的容器实例来扩展核心容器的功能。这个核心容器就是我们的Application，而Sidecar容器，是Istio基于Envoy的代理。 84 | 85 | 如上图所示，注入之后，所有的出入Application容器的通信，都将被这个代理劫持（使用IPTables）。 86 | 87 | 通过这种方式，Istio就能控制通信，以及向控制平面报告发生了什么。确切来说，是报告给作为遥测和策略引擎的Mixer。 88 | 89 | ## 它们之间的共同点是什么？ 90 | 91 | 我们已经明确了这两种技术，你发现了什么共同点？它们试图解决不同的问题，但是使用的是相同的技术...... 92 | 93 | 这两个方案有一点共同之处： 94 | 95 | ![common thing](https://ws4.sinaimg.cn/large/006tNc79gy1fvpc37snftj30xc0lwwhf.jpg) 96 | 97 | 但是记住这一点很重要，它们的流量限制分别用来处理不同的事务：业务规则和基础设施之间的限制。 98 | 99 | 因此，它们并不是互斥的，我们应该把它们当做基础设施的不同层面： 100 | 101 | 1. API Management：处理对API的访问，基于开发者、订阅计划、Application、账单等等。 102 | 2. Service Mesh：让你的API变得更安全，便于监控，以及弹性能力。 103 | 104 | ## 我们如何将3scale API Management和Istio Service Mesh结合起来？ 105 | 106 | 3scale是如何将API Management的能力添加到Istio Service Mesh的？请继续关注我们更多的技术发布，你可以使用我们的[API Gateway APIcast](https://github.com/3scale/apicast)或者使用[3scale Istio Adapter](https://github.com/3scale/istio-integration/tree/master/3scaleAdapter)原生地扩展Istio。 107 | 108 | -------------------------------------------------------------------------------- /2018/09/going-beyond-container-orchestration/index.md: -------------------------------------------------------------------------------- 1 | > 原文地址： 2 | > 3 | > 作者：[Lori MacVittie](https://aspenmesh.io) 4 | > 5 | > 译者：[甄中元](https://github.com/meua) 6 | > 7 | > 校对：[宋净超](http://jimmysong.io) 8 | 9 | # 超越容器编排 10 | 11 | 最近的几次关于容器使用情况的调研都得到了相似的结果，开发团队不仅采用而且开始拥抱容器技术。大多数人并没有像超大型组织那样大规模的使用容器。在一项思科赞助的调研中发现有超过8000家企业在生产环境中使用容器。这听起来令人印象深刻，但他们使用容器的规模有限。在[戴尔EMC，英特尔和红帽委托的Forrester报告]()中，63％使用容器的企业运行的实例超过100个，82％预计到2019年会达到这一规模。这与超大型技术公司使用的数十万的规模相距甚远。 12 | 13 | 虽然采用率很高，这并不是说组织使用容器的道路就是一帆风顺的。采纳任何一样新技术都是存在挑战的。人们使用容器时最关心的是：网络和管理。其次才去关注安全性和不一致性。 14 | 15 | ![](https://ws4.sinaimg.cn/large/006tNbRwly1fw4i0hfkbgj30s80koq5c.jpg) 16 | 17 | 网络挑战是由于Kubernetes等流行的容器编排软件所带来的。Kubernetes构建的就是要支持微服务架构。这允许开发和运维人员将功能抽象成一组pod，并将其作为“service”暴露出来，并通过定义好的API进行访问。Kubernetes支持DNS和基于TCP的L4负载均衡。 18 | 19 | 基于TCP L4负载均衡的问题是它无法与L7(应用程序和API层）交互。对于任何L4负载均衡都是如此；它不是容器和Kubernetes独有的东西。L4负载均衡提供了对连接级别（TCP）协议和指标的可见性，但仅此而已。这使得很难（真的不可能）解决高阶问题，例如每秒请求数或事务等L7指标以及基于路径分割流量（路由请求）。这也意味着您无法在API层进行速率限制或支持重试和断路等关键功能。 20 | 21 | 因为缺乏这些功能，开发人员就不得不将它们编码到每个微服务中。这导致运维代码包含在业务逻辑中。这明显不太合适，因为它显然违反了微服务设计的原则。因为它为微服务增加了构建和技术债。 22 | 23 | 虽然Kubernetes特别擅长处理容器化应用程序的构建和部署，但是它缺乏在运行时监控基于微服务的应用程序所需的关键功能。Kubernetes只能提供基本的健康检查存活探针和就绪探针，不能为开发和运维人员提供在执行期间快速有效地诊断问题所需的度量和追溯微服务的调用。让开发人员使用微服务来生成一致的指标可能是一项重大挑战，尤其是当他们要在限定时间内完成客户所需功能时，这会给他们带来很大的压力。 24 | 25 | 而Service Mesh是解决kubernetes在网络和管理方面问题的完美解决方案。 26 | 27 | ## Service Mesh如何应对挑战 28 | 29 | Service Mesh通过在Kubernetes的一些列pod中注入sidecar代理能够很好的解决这些问题。通过直接注入到容器环境，sidecar代理能够透明化网络和一致度量指标。由于所有流量都通过sidecar代理进行有效路由，因此它可以自动生成并将所需的指标提供给网格的其它部分。对于在容器环境中部署传统应用程序的组织而言，这非常有价值。传统应用程序不太可能适用于现代环境。使用Service Mesh及其sidecar代理基本使这些应用程序能够产生正确的指标，而无需或很少需要添加/修改代码。 30 | 31 | 这也意味着您不必花时间协调由各种运行时代理生成的不同指标。您可以依靠服务网格在所有应用程序和微服务中生成一致的度量标准集合。 32 | 33 | 这些指标包含提供给网格的更高阶数据点，并启用更高级的网络以确保对请求的最快可用响应。在Service Mesh中重试和断路器由sidecar代理处理，这减轻了开发人员将运维代码引入其微服务的负担。由于sidecar代理不受限于L4负载均衡（TCP），所以靠L7负载均衡（应用程序和API层）它支持更高级别的消息路由技术。 34 | 35 | ![](https://aspenmesh.io/wp-content/uploads/2018/09/service-mesh-vs-container-orch.jpg) 36 | 37 | 容器编排是一个很好的基础设施，但企业组织需要的不仅仅是一个良好的基础设施。他们需要能够与堆栈上层的服务进行交互的能力，这需要使用指标和现代架构去实现。 38 | 39 | 服务网格可以很好的提供这两种服务。当您需要超越容器编排时，请使用服务网格。 40 | -------------------------------------------------------------------------------- /2018/09/istio-service-mesh-interview-harrington/index.md: -------------------------------------------------------------------------------- 1 | # Istio 101：Service Mesh的未来将与Knative和Apahce Whisk等技术和谐共存——采访RedHat的Istio产品经理 2 | 3 | > 原文链接：https://jaxenter.com/istio-service-mesh-interview-harrington-148638.html 4 | > 5 | > 作者：[Gabriela Motroc](https://jaxenter.com/istio-service-mesh-interview-harrington-148638.html#authors-block) 6 | > 7 | > 译者：殷龙飞 8 | > 9 | > 审校：宋净超 10 | 11 | Istio正在引发大量的关注，特别是1.0版本发布后。但它是否成为Kubernetes之上的事实的服务网络标准呢？ 我们采访了Red Hat的Istio产品经理“红胡子”Brian Harrington，他的答案是肯定的。“有了Istio，部署很简单，与Kubernetes的集成也是浑然一体的。感觉就应该是这样。“ 12 | 13 | ![红胡子 Brian Harrington](https://ws4.sinaimg.cn/large/006tNbRwgy1fvcqw67cllj30lc0qodj9.jpg) 14 | 15 | 图片：红胡子 Brian Harrington 16 | 17 | Istio [1.0](https://jaxenter.com/istio-1-0-arrived-core-features-ready-production-use-147459.html) 在今年8月初发布，所有[核心功能](https://istio.io/about/feature-stages/)现在都可以用于生产。 18 | 19 | 如果您已经熟悉0.8中提供的功能，那么您应该知道1.0中提供的新功能列表并不长；该团队选择专注于修复错误并提高性能。如果您想看看Istio 1.0中引入的所有更改，可以阅读[发行说明](https://istio.io/zh/about/notes/1.0/)。 20 | 21 | 我们与Red Hat的Istio产品经理“红胡子”Brian Harrington讨论了他最喜欢的功能，Istio的未来以及它是否具备成为Kubernetes事实上的服务网络标准的功能。 22 | 23 | ## Istio改变游戏规则？ 24 | 25 | **JAXenter：Istio可能相对较新，但这种用于连接、管理和保护微服务的工具正在获得广泛的支持。增长背后的原因是什么？** 26 | 27 | **“红胡子”Brian Harrington：** 最大的原因是范式的转变。在 [Netflix的OSS](https://netflix.github.io/) （开放源代码软件套件）带来了很多强大的功能，个人开发企业级Java应用程序，但它要求你为了实现整个套件的而整合各种软件库。Istio令人兴奋，因为它为用户提供了A/B测试、断路、服务授权等功能，同时最大限度地减少了代码更改。 28 | 29 | **JAXenter：Google最近宣布的[云服务平台](https://jaxenter.com/google-cloud-interesting-announcements-147230.html)以Istio（和Kubernetes）为核心。这对Istio的未来意味着什么？** 30 | 31 | **“红胡子”Brian Harrington：** 这表明该领域的老牌企业已经认识到了一项卓越的技术，并且明白早期合作将为客户带来更大的成功。反过来，如果客户成功，采用的供应商提供的解决方案也会增加。 32 | 33 | **JAXenter：Istio能否成为Kubernetes事实上的服务网络？** 34 | 35 | **“红胡子”Brian Harrington：** 我敢肯定会的。其他解决方案通常是在操作组件，这些组件不是以云原生主体为基础构建的，因此可能总是感觉有点笨拙。使用Istio，部署非常简单，与Kubernetes的集成也浑然一体。感觉好像应该一直存在。 36 | 37 | **JAXenter：在Istio 1.0中你最喜欢的功能是什么？** 38 | 39 | **“红胡子”Brian Harrington：** 我最喜欢的功能是能够自由控制流量的路由。过去运行服务时，总是需要昂贵的专用负载均衡硬件的组合才能实现该功能，还要修改应用程序，有时候甚至需要重写一个才能良好运行。 40 | 41 | 在Istio中，将10％的流量分配到不同版本的服务并将这些连接路由到该版本的服务十分简单。围绕该功能的易用性改变了游戏规则。 42 | 43 | **请参见：[Istio 1.0发布，已生产就绪！](http://www.servicemesher.com/blog/announcing-istio-1.0/)** 44 | 45 | **JAXenter：Istio的未来是模块化的吗？** 46 | 47 | **“红胡子”Brian Harrington：** 模块化是Istio未来的一部分。Istio规定了某些需要满足的接口，然后允许用户使用他们最熟悉的软件来满足这些接口。 这在“Nginmesh”项目中最为明显，其中Envoy（Istio的代理组件）被Nginx取代。 48 | 49 | 其他用户同样可以用Linkerd取代了Envoy。 50 | 51 | **JAXenter：使用Istio最大的好处是什么？** 52 | 53 | **“红胡子”Brian Harrington：**Istio最耀眼的一个特点是它专注于应用程序的安全性。设置双向TLS的功能可自动解锁其他高级功能，例如服务授权以及服务之间的加密。Istio还具有与其他 [SPIFFE](https://spiffe.io/) （适用于所有人的安全生产身份框架）兼容系统集成的能力，这将有助于推动未来采用更高度安全的应用程序。 54 | 55 | 随着时间的推移，我希望看到安全特性进一步扩展，包括类似于Google的[身份识别代理的功能](https://cloud.google.com/iap/) 。关于这一点的好处是，通过对JSON Web token的支持和对OpenID Connect的支持奠定了一些基础。 56 | 57 | **还请参见： [Google Cloud Next '18：云开发人员所希望的一切](https://jaxenter.com/google-cloud-interesting-announcements-147230.html)** 58 | 59 | **JAXenter：Istio有什么Linkerd身上不具备的东西吗？** 60 | 61 | **“红胡子”Brian Harrington：**Istio拥有一个蓬勃发展的社区，正以惊人的速度增长。顺便提一下，Istio已经存在了大约 [21个月](https://github.com/istio/istio/commit/0216e811e9da88b867742710f7d166cef2eabfbc) ，在GitHub上有超过200个贡献者和一个非常活跃[pulse](https://github.com/istio/istio/pulse)（即使你忽略像Fortio这样的子项目只看Istio核心项目）。而Linkerd已经存在了近[31个月](https://github.com/linkerd/linkerd/tree/37e38f2a892d9354eea7305135aa6370612b02f2)。即使你结合[Linkerd v1](https://github.com/linkerd/linkerd/pulse)和[Linkerd v2](https://github.com/linkerd/linkerd2/pulse/) 的“pulse” ，它们的活跃度比起Istio仍然相去甚远。 62 | 63 | **JAXenter：您能展望下服务网格的未来吗？** 64 | 65 | **“红胡子”Brian Harrington：** 我相信服务网格的未来与无服务器计算（Serverless）有关。 我们正在融合开发人员成功地将代码库分解为原子组件的状态。 66 | 67 | 这种趋势甚至反映在围绕Istio模块化的问题上。我觉得服务网格的未来是与Knative和Apache Whisk等技术共生的，它使开发人员能够重新采用“仅做一件事并把它做得好”（do one thing and do it well）的“UNIX哲学”，以建立应用的未来。 68 | -------------------------------------------------------------------------------- /2018/09/microservice-observability-with-istio/index.md: -------------------------------------------------------------------------------- 1 | > 原文地址： 2 | > 3 | > 作者：[Eric Lee 和 Ian Morgan](https://www.trulia.com) 4 | > 5 | > 译者：[甄中元](https://github.com/meua) 6 | > 7 | > 校对：[宋净超](http://jimmysong.io) 8 | 9 | # Istio针对微服务可观测性 10 | 11 | ![](https://ws4.sinaimg.cn/large/006tNc79gy1fvmzdkbqh3j30rs0fmta7.jpg) 12 | 13 | Kubernetes和Istio如何帮助Trulia消除PHP单体架构，并用可持续的微服务架构取代。这篇博文是我们关于偿还欠下的技术债和重新构建我们平台的系列文章的延续。您可以阅读这篇介绍性文章：[聚焦未来的技术债](https://www.trulia.com/blog/tech/paying-off-tech-debt/)。 14 | 15 | ## 引言 16 | 17 | Trulia致力于将www.trulia.com单体应用分解成面向服务（SOA）的架构。所有支持的APIs和服务都将替换成工程部门AWS账号下拥有的各种功能单元。许多遗留AWS服务都是通过AMI映像promotion进行部署的，并使用各种不同的方法实现可观测性。将测量工具添加到代码库和基础架构所需的手动操作一直是个传统痛点。此外，这种用于构建可观测性的手动、个性化方法意味着没有单一的代码库可以在增强和工具上进行协作。 18 | 19 | ![](https://ws1.sinaimg.cn/large/006tNc79gy1fvmzdtyqq1j30sg0bpaap.jpg) 20 | 21 | 在2017年。我们就决定在同一的编排平台[kubernetes](https://kubernetes.io/)上构建我们所有的微服务。我们希望标准化微服务的指标、监控、流控等技术。 22 | 23 | SOA架构没有提供统一的可观测方法。了解微服务生态系统中有关请求率、错误率和延迟的情况被留给各个团队进行管理。这导致每个团队使用包含多个供应商和其他snowflake解决方案的不同工具集。所有这些工具的访问和授权也由各个微服务所有者自己管理，这样导致了没有一个地方可以把系统作为整体来管理，这样加大了管理的难度。许多不同AWS账户、仪表板和工具集之间错误诊断反复出现。 24 | 25 | 此外，由于每个EC2实例的生命周期不同、自动缩放和微服务代码库也是单独管理的，整个工程组无法共同改善这种状况。如果您设法改进了一个基于Java的微服务中聚合HTTP响应码为500，则无法与另一个尝试执行相同操作的团队一起传播或共享此更改。我们正在寻找其他解决方案。 26 | 27 | 我们希望构建一个平台，将基本可观测性问题与构建微服务的用户分开，允许在使用该平台的所有微服务之间实现连接和可观察性的独立和共享创新。我们选择的技术是容器和kubernetes的补充istio。 28 | 29 | ## 解决途径 30 | 31 | ![](https://ws3.sinaimg.cn/large/006tNc79gy1fvmzicivg0j30sg0di75b.jpg) 32 | 33 | 我们使用Istio透明代理我们的Kubernetes工作负载中的所有通信。将所有遥测集合移出进程，将其与单个微服务的代码库分离。 34 | 35 | Istio由三个部分组成：Pilot、Mixer和Citadel。Pilot管理Envoy实例间的策略，Mixer管理配置每个Envoy代理，Citadel管理双向TLS和其他安全相关功能。我们遇到了使用该工具的一些直接挑战，包括打包和安装问题，自动pod注入功能以及作为独立Ingress的Istio的SNI/供应商支持。 36 | 37 | 作为早期采用者为了克服这些挑战，我们与Google和[Tetrate.io](https://www.tetrate.io/)的核心Istio团队密切合作。这种关系帮助我们避免了常见的陷阱，并为istio核心团队提供了直接的反馈，验证了他们的路线图，并促进了我们在易用性改进方面的合作。 38 | 39 | 我们不期望我们的用户能够完全了解服务中的Istio，只需与本地Kubernetes服务发现机制进行交互以查找其他服务。Istio支持透明代理，因此微服务仅使用Kubernetes的本地服务发现机制。使用单一技术进行检测还为我们提供了一组标准的度量标准名称、单位以及对集群内流量的推倒。 40 | 41 | ## Envoy提供的示例指标： 42 | 43 | ![](https://ws4.sinaimg.cn/large/006tNc79gy1fvmzlevo8oj30sg0pedl0.jpg) 44 | 45 | 上述在Prometheus中收集的指标，用于报警和Grafana绘图。Envoy 被注入到每个工作负载中，并采集有关请求率、延迟和响应代码等信息。 46 | 47 | ## 结论 48 | 49 | 随着[Trulia Neighborhoods](https://www.trulia.com/blog/tech/trulia-neighborhoods/)社区即将启动，Istio的可观测性变得显而易见。社区团队的开发人员与性能工程师友好合作，能够识别导致极大的关键性能指标延迟的多个问题。 50 | 51 | 使用Jaeger发现驻留在Kubernetes集群之外的多个慢速遗留服务。基于SLA针对未来需求的性能指标，我们很容易联系服务开发人员优化和扩缩容新接口的开发设计。运维工程师不需要对此进行修复，而这之前需要多个团队和多个系统浪费很大的精力。 52 | 53 | 在kubernetes和istio的帮助下，Trulia能够分解PHP单体架构替换成可持续交付的微服务架构。团队不再被迫手动将工具添加到单个代码库或基础架构自动化中。我们的工程师有权部署具有开箱即用的可观测性和单一指标来源的新的微服务。我们对新架构的自由选择以及学习、改进和创造的机会感到非常兴奋。 54 | 55 | 请继续关注未来的文章，这些文章涉及微服务策略、可观测性和测试等相关主题！ 56 | -------------------------------------------------------------------------------- /2018/09/nginx-ingress-vs-kong-vs-traefik-vs-haproxy-vs-voyager-vs-contour-vs-ambassador/index.md: -------------------------------------------------------------------------------- 1 | > 原文地址： 2 | > 3 | > 作者：[Steven Acreman](https://kubedex.com) 4 | > 5 | > 译者：[navy](https://github.com/meua) 6 | > 7 | > 校对：[宋净超](http://jimmysong.io) 8 | 9 | # nginx-ingress/kong/traefik/haproxy/voyager/contour/ambassador/istio ingress 10 | 11 | 据我所知，这是kubernetes可用网关的最完整的列表。从技术上来讲，ambassador不是ingress，但是它表现地已经非常好了。你可能已经看到了我制作的大表。 12 | 13 | 下面有个连接可以打开并清晰的看到一个excel表格，包含了图表的详细内容，如果发现不正确的地方，请在文章末尾留言，我将及时修改。 14 | 15 | ![](https://i0.wp.com/kubedex.com/wp-content/uploads/2018/09/ingresses-updated-1.png?resize=1024%2C465&ssl=1) 16 | 17 | [查看全表请点击这里](https://docs.google.com/spreadsheets/d/16bxRgpO1H_Bn-5xVZ1WrR_I-0A-GOI6egmhvqqLMOmg/edit?usp=sharing)。 18 | 19 | 基于这些特点和我自己的经验、从别人的描述和其他相关文章中得知，我尝试着给每一个网关提供了一些选择的参考条件。下面描述先后顺序没有特别含义。 20 | 21 | ## 1. ingress-nginx 22 | 23 | 这可能是最常用的ingress。安全、简单可靠。支持http、https和ssl termination。你可能还想通过它支TCP、UDP，但是从GitHub上提的issue来看，目前你最好别这样做。您可以获得一些良好负载均衡选项以及强大的路由，websocket支持，基础身份认证和追踪。 24 | 25 | 但是没有动态服务发现有点遗憾。有个配置生成器可以自动生成但还是不太完美。 26 | 27 | 注意：我们在这里谈论的内容有官方的Kubernetes ingress。还有来自Nginx公司的Ingress有些设置不一样。 28 | 29 | ## 2. Kong 30 | 31 | 绝大多数的人认为Kong只是API网关。它有扩展插件系统使它的功能远远超出了正常ingress该有的功能。我不会使用它去做通用的负载均衡但是如果你想用它做API管理也是一个不错的选择。 32 | 33 | ## 3. Traefik 34 | 35 | Traefik的功能多的让我惊讶。它的弹性伸缩功能很棒，而且我们从很多博客上可以了解到它运行稳定。如果您当前正在使用ingress-nginx，那么为了让它支持动态配置将是一个很大的升级。事实上，没有理由让我不去用traefik。而且它应该会比现在更加出名。 36 | 37 | 唯一的缺点是它只支持http、https和grpc。如果你非需要TCP负载均衡，那么您需要选择其他方案了。 38 | 39 | ## 4. HAProxy 40 | 41 | 它是负载均衡算法之王。它似乎也非常适合负载均衡TCP连接。这是官方的HAProxy ingress，在生产环境使用的经验告诉我们它具有极其稳定的记录。如果需要，您还可以获得付费支持订阅。 42 | 43 | ## 5. Voyager 44 | 45 | Voyager是一个基于HAProxy的Ingress。完美封装了HAProxy并提供了很好的文档说明。我没有看到负载均衡算法的配置位置，所以假设它只是默认为轮询。如果那是错的，请在评论中告诉我，我会更新。 46 | 47 | ## 6. Contour 48 | 49 | 基于Envoy，它有一些更现代的功能，如支持金丝雀部署。它还具有一套良好的负载均衡算法，并支持多种协议。与列出的其他Ingress不同，我从Github那里了解到它仍处于快速发展阶段，有望添加更多功能。 50 | 51 | ## 7. Ambassador 52 | 53 | 如上所述，如果你遵循严格的kubernetes定义，那么这个技术上它并不算是一个Ingress。使用Ambassador您只需简单注释您的服务，它就像一个ingress路由流量。Ambassador有一些非常酷的功能，其他任何一个Ingress都没有像影子流量那样允许您通过镜像请求数据在实时生产环境中测试服务。 54 | 55 | Ambassador与Opentracing和Istio很好地集成。 56 | 57 | ## 8. Istio Ingress 58 | 59 | 如果您已经在运行Istio，那么这可能是一个很好的默认选择。它具有Ambassador拥有的一些更现代的功能。它也有故障注入，看起来可能很有趣。然而，Istio目前在这个领域做了很多工作，并且已经从Ingress转向Gateway。因此，如果您正在寻找每5秒钟没有发生变化的Ingress，您可能仍然需要考虑Ambassador。 60 | 61 | ## 总结 62 | 63 | 这里没有明显的赢家，因为你需要根据你的需求选择合适的Ingress。目前没有某一个Ingress可以做到这一切。 64 | 65 | 我建议您使用Ambassador。如果您只是运行标准的基于http的微服务并且喜欢了解技术前沿，那么你应该毫不犹豫的选择Istio，Ambassador和Jaeger。 66 | -------------------------------------------------------------------------------- /2018/09/the-importance-of-control-planes-with-service-mesh/index.md: -------------------------------------------------------------------------------- 1 | > 原文地址： 2 | > 3 | > 作者：[Daniel Bryant](https://dzone.com/users/1161205/daniel-bryant-uk.html) 4 | > 5 | > 译者：[navy](https://github.com/meua) 6 | > 7 | > 校对：[宋净超](http://jimmysong.io) 8 | 9 | # 服务网格的控制平面和边缘代理的重要性 10 | 11 | 本文将带您了解为什么服务网格和边缘代理如此重要以及它们与持续交付的关系。 12 | 13 | 了解现代云架构如何使用微服务具有的许多优势，使开发人员能够以CI/CD方式交付业务软件。 14 | 15 | 去年，Matt Klein写了一篇精彩的博客“[服务网格中的数据平面与控制平面](https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc)”。尽管我已经很熟悉“控制面板”这个术语，Matt再次加深了我对这个概念的理解以及与软件持续交付有关的重要性，特别是在入口/边缘网关和服务网格周围的部署控制（和细微差别）方面。 16 | 17 | 我之前写过关于边缘代理和API网关在软件交付中可以发挥的作用，持续交付：API网关有什么作用？像Envoy这样的现代代理在“云原生”应用程序操作中所产生的影响，我们进行了几次讨论。我得出的结论是，尽管微服务为具有动态编排的容器和云技术的使用提供了新的机会，但是剩下的核心挑战就是控制平面必须进行调整才能跟上变化。 18 | 19 | ## 控制平面和角色 20 | 21 | 在Matt的文章中，他指出服务网格控制平面“为网格中所有正在运行的数据平面提供策略和配置”，并且“控制平面将所有数据平面转变为分布式系统。”最终，控制平面的目标是设置将由数据平面制定的策略。控制平面可以通过配置文件，API调用和用户界面来实现。选择的实现方法通常取决于用户的角色，以及他们的目标和技术能力。例如，产品所有者可能想要在应用程序中发布新功能，这里UI通常是最合适的控制平面，因为这可以显示系统的可理解视图并且还提供一些导轨。但是，对于想要配置一系列低级防火墙规则的网络运维人员，使用CLI或配置文件将提供更细粒度（高级用户风格）控制，并且还便于自动化。 22 | 23 | 控制平面的选择也可能受所需控制范围的影响。我的同事[Rafi之前在QCon SF讨论过这个问题](https://www.infoq.com/news/2017/11/service-oriented-development)，集中或分散运维的要求肯定会影响控制平面的实施。这也直接关系到控制影响应该是本地的还是全局的。例如，运维团队可能希望指定全局合理的默认值和安全措施。但是，在前线工作的开发团队需要对其本地服务进行细粒度控制，并且可能（如果他们正在接受“自由和责任”模式）覆盖安全措施的能力。Matt还在最近的[QCon纽约演讲](https://www.infoq.com/news/2018/07/qcon-klein-service-mesh)中谈到了本地/全局互动，并展示了Lyft团队为服务到服务和边缘/入口代理创建的仪表板： 24 | 25 | ![](https://cdn-images-1.medium.com/max/800/1*QjLNa1Wh0Y_F87JghLpPUA.png) 26 | 27 | ## 东西向流量与南北向流量 28 | 29 | 软件应用中流量有两种典型分类，其中之一是南北向流量，通常称为入口流量，流量流向外部系统或者外部服务调用内部系统。另外一个是东西向流量，通常称为数据中心内部流量，这是在（可能是虚拟化的）内部网络边界内流动的流量 30 | 31 | 所谓东西向，大家能理解吧？东西向指服务间通讯，也就是A服务调用B服务。对应的还有南北向，南北向通常是指从外部网络进来调用服务，如走API Gateway调用服务。在东西向通讯中，我们有时会需要一个比较特殊的途径，比如说在这个图中，我们有两个集群，两个集群各有各自的服务注册中心。我们通过增强Pilot的方式打通两个注册中心，可以知道对方有什么服务。 32 | 33 | ![](https://ws1.sinaimg.cn/large/00704eQkgy1fsy0kakg35j30qo0f0dpi.jpg) 34 | 35 | _图片来自敖小剑的分享_ 36 | 37 | 在现代云原生应用程序中，两个独立的组件通常控制这些流量：API网关或边缘代理处理南北流量，相对的service mesh处理东西向流量。在Kubernetes域内，Ambassador 开源API网关可以处理入口流量，而[Istio](https://istio.io/)开放平台可以处理跨服务流量。 38 | 39 | 对于南北向和东西向代理组件，底层网络技术可以是相同的（例如使用[Envoy](https://www.envoyproxy.io/)）。但是，控制平面通常是不同的，基于与系统交互的角色。 40 | 41 | Ambassador控制面板的主要目标是开发人员，并允许将简单的注释添加到Kubernetes配置中以控制核心部署功能，如路由、金丝雀发布、速率限制。 42 | 43 | Istio关注的主要角色是运维人员，并且控制平面允许指定额外的Kubernetes资源以促进流量管理（包括故障注入）、安全（基于角色的访问控制和认证安全）和遥测（包括分布式追踪和各监控指标）。 44 | 45 | ## 结论：分歧或趋同 46 | 47 | Lyft使用Envoy作为边缘代理和service mesh，我还听到有工程师使用Ambassador 来管理服务间（东西向）通信的报道，以及Istio处理入口流量（甚至在[v1.0发布](https://www.infoq.com/news/2018/08/istio-1.0-service-mesh)的新网关功能之前），然而，目前Ambassador和Istio所代表的代理技术控制平面的两种方法似乎为开发和运维各自的角色提供了好处。鉴于我们对现代容器网络的整体知识和经验状况，我还不确信有一个简单的一刀切解决方案。因此，我认为在用于管理南北和东西流量的统一控制平面终极解决方案出现之前可能出现分歧。 48 | -------------------------------------------------------------------------------- /2018/10/does-the-service-mesh-spell-the-end-for-middleware/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://www.cloudops.com/2018/09/does-the-service-mesh-spell-the-end-for-middleware/ 3 | translator: roganw 4 | reviewer: rootsongjc 5 | title: "服务网格是中间件的终结者吗？" 6 | description: "本文分别介绍了中间件和服务网格，以及两者之间的权衡。" 7 | categories: "译文" 8 | tags: ["中间件","服务网格","Service Mesh"] 9 | date: 2018-10-16 10 | --- 11 | 12 | # 服务网格是中间件的终结者吗？ 13 | 14 | 在Istio和相关技术持续获得增势之时，中间件在Service Mesh中的地位正在逐渐减弱。尽管它们都可以用来监管不同应用和服务之间的通信，但是在运维和范式方面却大不相同。在今天以容器为中心的世界里，面向服务的架构体系盛行，中间件会变得无关紧要吗？ 15 | 16 | ## 中间件 17 | 18 | [中间件](https://searchmicroservices.techtarget.com/definition/middleware)将应用和它底层的数据库连接起来，因此常被称作“软件胶水”。它将客户端的网络请求连接到后端数据，通过将所有消息聚合到一个管道中来实现通信。中间件在这个管道中整合一些关键功能，包括安全验证、日志记录、路由、性能监控和消息转换。中间件以传统的方式整合面向服务架构（[SOA](https://searchmicroservices.techtarget.com/definition/service-oriented-architecture-SOA)）应用的通信，后者由可复用的组件组成或者是一个单体应用。 19 | 20 | 如下图所示，中间件的工作方式，是将不同应用的消息汇总到中心化的通信节点。然后将这些消息传递到一系列功能管道，直到“用户注册”服务。消息通过企业服务总线（ESB）进行传输。这种通信方式便于隐藏分布式系统的多样性、硬件和操作系统的差异性。 21 | 22 | ![中间件](https://ws3.sinaimg.cn/large/006tNbRwgy1fwg4xtztzlj31kw13sk09.jpg) 23 | 24 | 随着企业组织持续拥抱容器化，传统中间件的一些问题开始变得愈加明显。DevOps实践鼓励基于分布式系统的现代环境，以及快速、自动化部署的不可变实例。容器的持续集成和持续交付（CI/CD）要求不断地更新应用和工具，而ESB对比并不友好。 25 | 26 | 单点故障（Single-points-of-failure）：中间件以服务日志级别，记录和监控所有服务的消息，并保存在一个巨大的、中心化的日志系统中。它针对所有的消息都执行特定的功能，特别是日志记录和性能监控。消息被排队处理，任何故障都可能导致管道拥堵。要发现一个问题，可能需要从上千个无关的潜在错误中进行筛选。中间件实现通信的方式，有可能在记录服务日志时发生单点故障，一个小问题就能中断所有的通信。 27 | 28 | 单体应用（Monolithic）：尽管SOA由松耦合、可复用的组件组成，中间件的统一管道难以为之做出调整。中间件所整合的功能与它们自身和周围的应用紧密集成在一起，UI上的小变化甚至需要重新评估整个应用。中间件提供了一种通用的通信方式，在这方面它是有效的，但是这需要创建隔离网络的命令式编程。 29 | 30 | 容器化和虚拟化大大增加了应用中部署的实例数量，这也增加了发生单点故障时的拥堵风险，并且需要更加动态的变化。服务网格方案，如Istio、Ambassador和Envoy，正越来越多地被视为替代方案。 31 | 32 | ## 服务网格 33 | 34 | [服务网格](https://containerjournal.com/2018/07/27/introducing-a-security-mesh-to-protect-kubernetes/)是一个位于服务层之上的专用网络层，用于服务间通信。它的通信管道基于分布式APIs，而不是中心化、离散化的应用。 35 | 36 | 消息在服务网格内传输，但是消息传递功能在接收消息的服务旁侧执行，每个实例被附加了一个用于在服务网格中来回传递消息的代理。这些代理执行一些传统上由中间件执行的功能，比如消息路由、消息阻塞、服务发现、负载均衡、加解密、认证和授权。此外，它们也支持错误处理、熔断、请求追踪等特性。 37 | 38 | ![中间件](https://ws4.sinaimg.cn/large/006tNbRwgy1fwg4xah8wdj31kw104nlp.jpg) 39 | 40 | 服务网格允许在服务间直接发送消息，而不再通过中间管道。这使得应用的消息传递跟它的服务耦合在一起，而这在大多数中心化应用中是松耦合的。服务网格分布式的特性减轻了单点故障的依赖，并促进了动态变化。 41 | 42 | 容器化：服务网格在许多方面都是容器化的理想选择。它们是平台无关的，并且可以被集成到任何基于容器的体系架构中。它们消除了单点故障，可以从网络故障或服务故障中快速恢复。通过消息分发，它们使得容器化的可伸缩性和声明式编程更加容易。[服务网格支持容器化朝着高度易变的环境发展](https://devcentral.f5.com/articles/how-containers-scale-service-mesh-versus-traditional-architecture-27705)。基于这些原因，产生了越来越多的决策，使用诸如Istio之类的工具，将中间件的计算能力带入到Kubernetes和基于容器的系统。 43 | 44 | [Istio](https://www.cloudops.com/tag/istio/)是一个可以提供对服务网格的操作控制和行为洞察力的解决方案。它基于Envoy代理而构建。ELK、Kibana和EFK可以为Istio提供可观察性和可监控性。 45 | 46 | ## 中间件的终结？ 47 | 48 | 随着服务网格越来越多的被采纳，它们发展的非常迅速。最近，Istio发布了1.0版本，表明服务网络正变得更加稳定和安全。Envoy已经加入云原生计算基金会（[CNCF](https://www.cncf.io/)），Istio也正在计划加入。服务网格解决方案正在发展成为蒸蒸日上的云原生生态系统，并且被用于云原生应用。 49 | 50 | 但是，有些确定的用例场景仍然得益于稳定而安全的中间件。中间件已经存在了数十年，知道如何操作它的人比知道如何操作服务网格的人更多。另外，已经有些长期存在的、被证实过的措施用于确保中间件的安全性，并遵守相关规范，如HIPPA、PIPEDA和PCI DSS。 51 | 52 | [服务网格正在迅速地变得更加安全](http://blog.christianposta.com/how-a-service-mesh-can-help-with-microservices-security/)，但是容器安全与虚机安全有着不同的思维。除此之外，它依赖于将运维过程集成到开发阶段。在整个技术栈的实施过程中，DevOps实践促进了应用的安全、敏捷和长期演化。在实施DevOps方法论和相关流程的过程中，云原生工具已经成功起到了显著作用。 53 | 54 | 如果组织架构希望使用服务网格替代某些中间件，则必须重新评估其组织流程和方法论。尽管服务网格有助于多个容器间的通信，中间件仍然是单体应用间消息传递的理想选择。它们构建在不同的范例中，组织机构可能不得不从根本上改变他们构建应用和基础设施的方式，并且支持做出变化。 55 | 56 | 在DevOps工具和实践框架落实到位之前，组织机构并不能撤下部分遗留中间件。这将促进技术栈的基础设施（如代码、服务、安全性、监控和CI/CD）之间的动态协同。应用的中间件或者服务网格必须反映它们之间进行通信的组件。 57 | 58 | DevOps转型将有助于确保组织的文化和决策过程与其使用工具进行创新的速度保持一致。联系我们，[了解如何改变、支持和发展您的DevOps和云原生实践。](mailto: info@cloudops.com) 59 | 60 | -------------------------------------------------------------------------------- /2018/10/the-future-of-service-mesh-part-ones-ervice-mesh-architectures-inevitable/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://blogs.vmware.com/opensource/2018/10/16/service-mesh-architectures-inevitable/ 3 | author: Stephen McPolin，Venil Noronha 4 | translator: malphi 5 | reviewer: rootsongjc 6 | title: "服务网格的未来Part 1：服务网格架构势不可挡——并且越来越重要" 7 | description: "本文通过分析服务网格的优势，阐述了其未来的发展情况" 8 | categories: "译文" 9 | tags: ["Istio","Service Mesh"] 10 | date: 2018-10-26 11 | 12 | --- 13 | 14 | ## 服务网格的未来，第一部分：服务网格架构是必然趋势——并愈加重要 15 | 16 | 作者：Stephen McPolin，Venil Noronha 17 | 18 | 当[Istio 1.0](https://istio.io/)在几个月前发布时，[TechCrunch](https://techcrunch.com/2018/07/31/the-open-source-istio-service-mesh-for-microservices-hits-version-1-0/)称它为“可能是目前最重要的开源项目之一”。它并不是完美的(在本系列的第2部分会有详细介绍)，但是这个版本标志着服务网格架构开发的一个重要里程碑。 19 | 20 | 尽管对Istio的发布给予了关注，但是，在开源社区服务网格还是不为人知。在这两篇文章中，我们首先提供一个窗口让读者了解服务网格的功能，然后在第二部分，展望在不久的会有何收获。 21 | 22 | 关于服务网格，有一件重要的事情需要知道：那就是一旦微服务开始流行起来，服务网格基本上就变得不可避免了。这是因为本质上，它们运行并作为平台来解决服务之间通信的日益复杂的挑战。 23 | 24 | 它们是这样工作的：假设你有一个微服务用来在客户数据库中查找支付方式，另一个来处理支付流程。如果你想确保信息不会泄露，或者你要将客户信息关联到正确的支付处理程序，那么你需要对它们之间的通信进行加密。服务网格可以处理加密而不需要任何一个服务知道如何加密。 25 | 26 | 服务网格的作用远不止于此。总的来说，它们负责广泛的核心通信，包括： 27 | 28 | - 可观测性——在服务之间提供日志和度量数据 29 | - 发现——使服务连接在一起能够彼此发现 30 | - 通信——建立通信策略、方法和安全 31 | - 认证——建立服务和通信的访问权限 32 | - 平台支持——提供跨多个后端（Azure、AWS等）和编排（Kubernetes、nginx等）的能力 33 | 34 | 你可以看到它对开发人员的吸引力——在每次构建微服务时，服务网格会处理掉他们不愿处理的所有事情。对系统管理员和部署团队来说也是福音：他们不必为想把需要的功能构建到特定的微服务而与开发人员讨价还价。而且，至少在理论上客户也会从中受益，因为他们可以更快地部署为市场定制的服务。 35 | 36 | 考虑到这些优势，服务网格做到这一点将成为必然。一开始人们创造自己的通信网络。不久后公共的模式产生。统一的方法被整合在一起最终形成了平台解决方案。 37 | 38 | 两年前谷歌开源了自己的服务网格Istio。它不是第一个也不是最成熟的服务网格，但它是增长最快的，1.0版本的发布标志着服务网格开启了新的篇章。 39 | 40 | 再次引用TechCrunch的文章：“如果你不看好服务网络，这可以理解，的确有些人不看好他”。尽管目前情况是这样，但因为上述原因，我们认为这种情况很可能会改变。这就是为什么我们VMware花了大量的时间和精力在服务网格的开发上。 41 | 42 | 在姊妹篇的第2部分，将讲述如何在VMware如何开发开源的服务网格，并描述我们认为架构在成熟后所面临的主要问题。 43 | 44 | 请继续在[Open Source Blog](https://blogs.vmware.com/opensource/)关注我们的服务网格系列的第二部分 ，并在Twitter上关注我们（@vmwopensource）。 -------------------------------------------------------------------------------- /2018/10/the-future-of-service-mesh/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://blogs.vmware.com/opensource/2018/10/23/service-mesh-whats-next 3 | author: Stephen McPolin & Venil Noronha 4 | translator: shaobai 5 | reviewer: rootsongjc 6 | title: "服务网格的未来Part2，Istio 1.0之后何去何从？" 7 | description: "本文通过分析服务网格的优势，阐述了其未来的发展情况" 8 | categories: "译文" 9 | tags: ["Istio","Service Mesh"] 10 | date: 018-10-16，2018-10-24 11 | --- 12 | 13 | ## 服务网格的未来Part 2，Istio 1.0之后何去何从？ 14 | 15 | 在服务网格系列的第一部分中，我们认为服务网格是微服务体系架构发展的必然和有益的结果。随着 Istio 1.0 的发布，我们在服务网格领域已经经过了一个重要的里程碑，在这个重要的的时间节点上，我们需要思考服务网格的未来将如何发展。 16 | 17 | 在 VMware 我们非常愿意花时间和精力支持开源的服务网格架构。我们已经成为 Istio 和 Envoy（Istio 用来动态控制微服务的特定的开源服务代理）的贡献成员。我们在改善网络方面投入了大量的精力，同时在其他领域贡献力量。 18 | 19 | 我们考虑到几乎每个 Istio 的演示目前都是基于一个单一的示例。保加利亚的一位 VMware 同事目前正在构建一个全新的 Istio 演示示例，用于演示如何在封闭字幕等服务之间管理视频质量，并演示 Istio 在微服务环境中的动态路由的能力。 20 | 21 | 因为我们认为服务网格是有价值的，而且可以一直存在，所以我们一只在寻求将 VMware 自己的世界级系统管理工具集与服务网格框架进行集成。这里有一个很好的例子，我们最近创建了一个适配器，将 Istio metrics 导出到 VMware 的 Wavefront 监测和分析工具中。如果我们能够将微服务中的更多信息合并到我们的系统管理工具中，我们相信这些工具能够更好的管理系统。 22 | 23 | ![](https://ws2.sinaimg.cn/large/006tNbRwgy1fwp4etrgwvj30sg0iz782.jpg) 24 | 25 | 从我们的角度来看，这样的工作是为了扩大微服务生态系统。然而，服务网格平台本身还不够完善。比如说，Istio 是一个复杂的软件，当它不能正常工作时很难调试。当它在工作，它能很好的帮助你监测你的微服务是否正常运行。当它不能正常工作，又很难弄清楚它为什么不能工作。这种复杂度已被社区中被广泛理解的，并且我们一直在花时间和精力思考如何克服这种复杂性，但目前我们还没有解决这个问题。 26 | 27 | 目前服务网格平台刚开始处理多集群情况。如果你将应用部署在单集群上，可以使用 Istio 和 Envoy 这样的应用管理他们。但是当你希望将单集群扩展到多集群，并让服务在集群边界上进行通信（从安全的角度来看是一个好想法），那这将是一个挑战。社区理解 Istio 这样的情况，于我们而言，正在逐步改进设计以支持多集群管理。 28 | 29 | 至此，我们正在关注一个新的提议，来自 Google 的 Knative。从根本上说，这是基于 Google 的“函数即服务”概念，从 Kubernetes 和 Istio 中衍生出来的。在不久的将来，它将向 Istio 提出更多的需求，但是目前还不清楚这些需求从何而来。例如，“事件”对于 Istio 来说是一个完全陌生的概念，但是对于处理临时数据还是必要的。Knative 则增加了这方面的组件，并推向 Istio 的下层。 30 | 31 | 现在，我们只是在看到 Space—Knative 推出了大约一个半月，并且还有很多问题没有解决，在我们决定如何应对这些问题之前，我们也在寻求新的变革。因此，现在还有很多的事情要做，同时也有很多需要关注的地方。但是可以肯定的是，服务网格会有持续发展。 32 | 33 | 请继续在 [Open Source Blog](https://blogs.vmware.com/opensource/) 关注我们对服务网格系列后续的更新，并在Twitter上关注我们（@vmwopensource）。 -------------------------------------------------------------------------------- /2018/11/design-patterns-for-microservice-communication/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://dzone.com/articles/design-patterns-for-microservice-communication 3 | translator: malphi 4 | author: Rajesh Bhojwani 5 | reviewer: rootsongjc 6 | title: "微服务通信的设计模式" 7 | description: "本文详细的介绍了同步和异步模式下微服务间的通信模式。" 8 | categories: "translation" 9 | tags: ["microservice"] 10 | date: 2018-11-26 11 | --- 12 | 13 | # 微服务通信的设计模式 14 | 15 | 在我的上一篇博客中，我谈到了[微服务的设计模式](https://dzone.com/articles/design-patterns-for-microservices)。现在我想更深入地探讨微服务架构中最重要的模式：微服务之间的相互通信。我仍然记得我们过去开发单一应用时通讯是一项艰巨的任务。在那时我们必须小心的设计数据库表和对象模型映射之间的关系。而现在在微服务中，我们已经将它们分解为独立的服务，并创建网格来彼此通信。让我们来谈谈迄今为止为解决这个问题而发展起来的所有通信方式和模式。 16 | 17 | 许多架构师已经将微服务之间的通信划分为同步和异步两种模式。让我们一个一个来介绍。 18 | 19 | ## 同步模式 20 | 21 | 当我们说到同步时，意思是客户端向服务端发出请求并等待其响应。线程将被阻塞，直到它接收到返回。实现同步通信最主要的协议是HTTP。HTTP可以通过REST或SOAP实现。现在REST在微服务方面发展迅速并超越了SOAP。对我而言两者都很好用。 22 | 23 | 现在让我们讨论同步模式中的不同的工作流、用例，我们面临的问题以及如何去解决。 24 | 25 | 1. 先从一个简单的例子开始。你需要一个服务A来调用服务B并等待实时数据的响应。这是实现同步的一个很好的选择，因为不会涉及到下游服务。如果使用多个实例，除了负载均衡之外，你不需要为这个用例实现任何复杂的设计模式。 26 | 27 | ![sync flow](https://ws2.sinaimg.cn/large/006tNbRwly1fxlg5e91x1j30fc04yt8l.jpg) 28 | 29 | 2. 现在让我们把它变得更复杂一点。服务A为实时数据调用多个下游服务，如服务B、服务C和服务D。 30 | 31 | - 服务B、服务C和服务D都必须按顺序调用——当服务相互依赖以检索数据，或者是有一个事件序列的功能需要被执行，就会出现这种情况。 32 | - 服务B、服务C和服务D可以并行调用——这种场景被使用在服务彼此独立或服务A可能扮演协调者（Orchestrator）角色时。 33 | 34 | ![sync flow2](https://ws1.sinaimg.cn/large/006tNbRwly1fxlgbk5vfbj30g609rwei.jpg) 35 | 36 | 这会为通信带来复杂性。让我们一个一个地讨论。 37 | 38 | ### 紧密耦合 39 | 40 | 服务A将与服务B、C和D耦合。它必须知道每个服务的端点（endpoint）和凭据（credentials）。 41 | 42 | **解决方案**： [服务发现模式](https://www.rajeshbhojwani.co.in/2018/11/design-patterns-for-microservices.html) 就是用来解决这类问题的。它通过提供查询功能来帮助分离消费者和生产者应用。服务B、C和D可以将它们自己注册为服务。服务发现可以在服务端也可以在客户端实现。对于服务端，有AWS ALB和NGINX，它们接受来自客户端的请求，发现服务并将请求路由到指定位置。 43 | 44 | 对于客户端，有Spring Eureka发现服务。使用Eureka的真正好处是它在客户端缓存了可用的服务信息，所以即使Eureka服务器宕机了一段时间，它也不会成为单点故障。除了Eureka，etcd和consul等其他服务发现工具也得到了广泛的应用。 45 | 46 | ### 分布式系统 47 | 48 | 如果服务B，C，D有多个实例，它们需要知道如何负载均衡。 49 | 50 | **解决方案**：负载均衡通常与服务发现携手出现。对于服务器负载平衡，可以使用AWS ALB，对于客户端可以使用Ribbon或Eureka。 51 | 52 | ### 验证/过滤/处理协议 53 | 54 | 如果服务B、C和D需要被保护并验证身份，我们只需要过滤这些服务的某些请求，如果服务A和其他服务使用不同的协议。 55 | 56 | **解决方案**：[API 网关模式（gateway）](http://www.rajeshbhojwani.co.in/2018/11/design-patterns-for-microservices.html) 有助于解决这些问题。它可以处理身份验证、过滤和将协议从AMQP转换为HTTP或其他协议。它还可以查看分布式日志、监控和分布式跟踪等可观测的指标（metrics）。Apigee、Zuul和Kong就是一些这样的工具。请注意，如果服务B、C和D是可管理的API的一部分，我建议使用这种模式，否则使用API网关就太重了。下面将要读到的服务网格是它的替代解决方案。 57 | 58 | ### 处理失败 59 | 60 | 如果服务B、C或D宕机，服务A仍然有某些功能来响应客户端请求，就必须相应地对其进行设计。另一个问题是：假设服务B宕机，所有请求仍然在调用服务B，并且由于它没有响应而耗尽了资源，这会使整个系统宕机，服务A也无法向C和D发送请求了。 61 | 62 | **解决方案**：[熔断器（Circuit Breaker）](http://www.rajeshbhojwani.co.in/2018/11/design-patterns-for-microservices.html) 和 [隔板（bulkhead） ](https://docs.microsoft.com/en-us/azure/architecture/patterns/bulkhead)模式有助于解决这些问题。熔断器识别下游服务是否停机了一段时间，并断开开关以避免向其发送调用请求。它将在定义的时间段之后再次尝试检查，如果服务已经恢复则关闭开关以继续对其进行调用。这确实有助于避免网络阻塞和耗尽资源。隔板模式有助于隔离用于服务的资源，并避免级联故障。Spring Cloud Hystrix就是做这样的工作，它适用于断路器和隔板模式。 63 | 64 | ### 微服务间网络通信 65 | 66 | [API 网关](http://www.rajeshbhojwani.co.in/2018/11/design-patterns-for-microservices.html) 通常用于管理API，它处理来自ui或其他消费者的请求，并对多个微服务进行下游调用并作出响应。但是，当一个微服务想要调用同组中的另一个微服务时，API网关就没有必要了，它并不是为了这个目的而设计的。最终，独立的微服务将负责进行网络通信、安全验证、处理超时、处理故障、负载平衡、服务发现、监控和日志记录。对于微服务来说开销太大。 67 | 68 | **解决方案**：服务网格模式有助于处理此类NFRs。它可以卸载我们前面讨论的所有网络功能。这样，微服务就不会直接调用其他微服务，而是通过服务网格，它将处理所有的通信。这种模式的美妙之处在于，你可以专注于用任何语言（如Java、NodeJS或Python）编写业务逻辑，而不必担心这些语言是否支持所有的网络功能。Istio和Linkerd解决了这些需求。我唯一不喜欢Istio的地方是它目前仅限于Kubernetes。 69 | 70 | ## 异步模式 71 | 72 | 当我们谈到异步通信时，它意味着客户端调用服务器，接收到请求的确认，然后忘记它。服务器将处理请求并完成。 73 | 74 | 现在让我们讨论一下什么时候需要异步。如果你的应用读操作很多，那么同步可能非常适合，尤其是在需要实时数据时。但是，当你处理大量写操作而又不能丢失数据记录时，你可能希望选择异步操作，因为如果下游系统宕机，你继续向其发送同步的调用，你将丢失请求和业务交易。经验法则是永远不要对实时数据读取使用异步，也永远不要对关键的业务交易写操作使用同步，除非你在写后立即需要数据。你需要在数据可用性和数据的强一致性之间进行选择。 75 | 76 | 有几种不同的方式可以实现异步： 77 | 78 | ### 消息 79 | 80 | 在这种方式中，生产者将消息发送到消息代理，而消费者可以监听代理来接收消息并相应地处理它。在消息处理中有两种模式：一对一和一对多。我们讨论了同步带来的一些复杂性，但是在消息传递中，默认情况下就会消除一些复杂性。例如，服务发现变得无关紧要，因为消费者和生产者都只与消息代理对话。负载均衡是通过扩展消息系统来处理的。失败处理是内建的，主要由message broker负责。RabbitMQ、ActiveMQ和Kafka是云平台中最流行的消息传递解决方案。 81 | 82 | ![msg flow](https://ws2.sinaimg.cn/large/006tNbRwly1fxlhh1zzvuj30kj0coaa7.jpg) 83 | 84 | ### 事件驱动 85 | 86 | 事件驱动方式看起来类似于消息传递，但它的用途不同。它不会发送消息，而是将事件细节连同负载（payload）一起发送到消息代理。消费者将确定事件是什么，以及如何对此作出响应。这会更加松散的耦合。有下面几种类型的负载可以被传递： 87 | 88 | - 全负载 —— 这将包含与消费者采取进一步行动所需的事件相关的所有数据。然而，这使得它的耦合更加紧密。 89 | - 资源 URL —— 这是一个指向代表事件的资源的URL。 90 | - 仅事件 —— 不会发送负载，消费者将基于事件名称知道如何从其他源（如数据库或队列）检索相关数据。 91 | 92 | ![event flow](https://ws4.sinaimg.cn/large/006tNbRwly1fxlhpapghaj30ll0a8mx7.jpg) 93 | 94 | 还有其他一些方式，比如编排（choreography），但我个人并不喜欢。它太复杂几乎无法实现，只能通过同步方式来完成。 95 | 96 | 以上就是本博客的全部内容。请让我知道你在微服务通信方面的经验。 -------------------------------------------------------------------------------- /2018/11/istio-what-happens-when-control-plane-is-down/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://bani.com.br/2018/11/istio-what-happens-when-control-plane-is-down/ 3 | translator: Waret 4 | reviewer: yangchuansheng 5 | title: "Istio: 控制平面出现故障以后会发生什么？" 6 | description: "本文展示了当Istio控制平面的组件出现故障以后会发生什么现象。" 7 | categories: "译文" 8 | tags: ["Istio","Istio Pilot","Istio Mixer Policy","Istio Mixer Telemetry"] 9 | date: 2018-11-16 10 | --- 11 | 12 | # Istio: 控制平面故障以后会发生什么？ 13 | 14 | 大家好！我在Istio上做了一些实验，禁用控制平面的组件，并观察应用和服务网格会发生什么。下面是我的笔记。 15 | 16 | ## Pilot 17 | 18 | Pilot负责Istio的流量控制特性，同时将Sidecar更新至最新的网格配置。 19 | 20 | Pilot启动以后，监听端口*15010*（gRPC）和*8080*（HTTP）。 21 | 22 | 当应用的Sidecar（Envoy，Istio-Proxy）启动以后，它将会连接*pilot.istio-system:15010*，获取初始配置，并保持长连接。 23 | 24 | Pilot会监听Kubernetes资源，只要检测到网格发生变化，就会将最新的配置通过gRPC连接推送到Sidecar上。 25 | 26 | - 当Pilot停止以后，Pilot和Sidecar之间的gRPC连接被关闭，同时Sidecar会一直尝试重连。 27 | - 网络流量不会受到Pilot停止的影响，因为所有的配置被推送过来以后，就会存储在Sidecar的内存中。 28 | - 网格中新的变更信息（例如新的Pod、规则、服务等等）不会继续到达Sidecar，因为Pilot不再监听这些变化并转发。 29 | - 当Pilot重新上线以后，Sidecar就会重新建立连接（一直尝试重连）并获取到最新的网格配置。 30 | 31 | ## Mixer Policy 32 | 33 | Policy执行网络策略。 34 | 35 | Mixer在启动时读取配置，并监听Kubernetes的资源变化。一旦检测到新的配置，Mixer就会将其加载至内存中。 36 | 37 | Sidecar在每次请求服务应用时，检查（发起连接）Mixer Policy Pod。 38 | 39 | 当Mixer Policy Pod停止以后，所有到服务的请求会失败，并收到 **“503 UNAVAILABLE:no healthy upstream”** 的错误——因为所有 sidecar 无法连接到这些Pod。 40 | 41 | 在Istio 1.1版本中新增了[global]配置（*policyCheckfailOpen*），允许 *“失败打开”* 策略，也即当Mixer Policy Pod无法响应时，所有的请求会成功，而不是报*503*错误。默认情况下该配置设置为 *false* ，也即 *“失败关闭”* 。 42 | 43 | 当Mixer停止后，我们在网格中执行的操作（例如新增规则、更新配置等等）都不会对应用产生影响，直到Mixer重新启动。 44 | 45 | ## Mixer Telemetry 46 | 47 | Telemetry为Istio插件提供遥测信息。 48 | 49 | Sidecar什么时候调用Telemetry Pod取决于两个因素：批量完成100次请求和请求时间超过1秒钟（默认配置），这两个条件只要有一个先满足就会执行该操作，这是为了避免对Telemetry Pod造成过于频繁的调用。 50 | 51 | 当Telemetry Pod停止以后，Sidecar记录一次失败信息（在Pod标准错误输出里），并丢弃遥测信息。请求不会受到影响，正如Policy Pod停止时一样。当Telemetry Pod重新启动以后，就会继续从Sidecar收到遥测信息。 52 | 53 | ## 其它信息 54 | 55 | 值得注意的是，Istio允许自定义控制平面的组件。例如，如果不需要Policy，你可以完全禁用Mixer Policy。Istio 1.1对这种模块化的特性支持的更好。更多信息，可以参考[这篇文档](https://istio.io/docs/setup/kubernetes/minimal-install/)。 56 | 57 | 当然，Pilot、Mixer Policy和Mixer Telemetry在高可用部署场景工作的也很好，可以同时运行多副本。实际上，默认配置通过*HorizontalPodAutoscaler*允许启动1到5个Pod。（详细请参考[这篇文档](https://github.com/istio/istio/blob/release-1.1/install/kubernetes/helm/subcharts/mixer/templates/autoscale.yaml#L15)和[这篇文档](https://github.com/istio/istio/blob/release-1.1/install/kubernetes/helm/subcharts/mixer/values.yaml#L14)） 58 | -------------------------------------------------------------------------------- /2018/11/service-mesh-meet-event-mesh/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://solace.com/blog/event-mesh 3 | author: Shawn McAllister 4 | translator: kelvinji2009 5 | reviewer: yiduwangkai 6 | title: "当Service Mesh遇见Event Mesh: Event-Driven型企业新的架构层" 7 | description: "本文主要介绍了 Event Mesh 是什么，Event-Driven 型企业为什么需要 Event Mesh 层。" 8 | categories: "translation" 9 | tags: ["Service Mesh", "Event Mesh"] 10 | date: 2018-11-23 11 | --- 12 | 13 | # 当 Service Mesh 遇见 Event Mesh: Event-Driven 型企业新的架构层 14 | 15 | [Service Mesh](https://www.nginx.com/blog/what-is-a-service-mesh/)被用作微服务的基础设施层，使通信变得更加灵活，可靠和快速。 它得到了谷歌、微软、IBM、红帽和 Pivotal 等行业巨头的推动，并且正在推出 Kubernetes、OpenShift 和 Pivotal Container Service（PKS）等平台和服务。 16 | 17 | 虽然 Service Mesh （服务网格）可以很好地支持同步 RESTful 和一般的<请求-回复>交互，但它不支持异步、事件驱动的交互，不适合将云原生微服务与遗留应用程序连接，也不适用于 IoT。 18 | 19 | 现代企业正在将事件驱动架构作为其数字化转型的一部分，每个事件驱动型的企业都需要一个中枢神经系统来快速、可靠和安全地将事件从它们发生的地方发送到它们需要去的地方。 20 | 21 | 这个中枢神经系统可以被视为 Event Mesh（事件网格） - 您架构中的一个新层。 22 | 23 | ![2018-10-23_13-36-58-copy-2.gif](https://3yecy51kdipx3blyi37oute1-wpengine.netdna-ssl.com/wp-content/uploads/2018/10/2018-10-23_13-36-58-copy-2.gif) 24 | 25 | 事件网格作为服务网格的补充，可以做为应用程序的连接层，以提供企业实现其数字化转型目标所需的全套应用程序间通信模式。 26 | 27 | ## 什么是 Event Mesh？ 28 | 29 | 事件网格对于事件驱动的应用程序，就好比是服务网格对于 RESTful 应用程序：一个架构层，无论在哪里部署这些应用程序（非云、公有云或者私有云），都可以动态路由某个应用程序的事件并使其被其他应用程序所接收。 事件网格由内部连通的 Event broker(事件代理)网络来创建和启用。 30 | 31 | ![](https://ws4.sinaimg.cn/large/006tNbRwly1fxmu7vq7crj30kh0cajsy.jpg) 32 | 33 | ## Event Mesh vs. Service Mesh 34 | 35 | 事件网格可以做为服务网格的补充。 事件网格和服务网格类似，它们可以在应用程序之间实现更好的通信，并允许应用程序通过将某些功能放在网络层和应用程序层之间，这样我们可以更多地关注业务逻辑。 但是，相比之下，也有一些重要的区别： 36 | 37 | - 服务网格连接云环境中的微服务，例如 Kubernetes，Amazon ECS、Google Kubernetes Engine、IBM Cloud 和 Alibaba； 38 | - 事件网格不仅连接微服务（容器化或其他），还连接遗留的应用程序、云原生服务以及可在云和非云环境中运行的各种设备和数据源/接收端。 事件网格可以将任何事件源连接到任何事件处理程序，无论它们在何处部署。 39 | 40 | ## Event Mesh 的特点 41 | 42 | 事件网格的定义有三个显著特征。 事件网格是： 43 | 44 | 1. 由内部连通的 Event Broker 形成的组合 45 | 2. 与环境无关 46 | 3. 动态的 47 | 48 | 事件网格由 Event Broker（1）网络创建和启用的事实意味着其本质上是事件驱动的。 49 | 50 | > “我相信事件将成为现代企业的生命线。” 51 | 52 | 与环境无关（2），我的意思是事件网格可以部署在任何公共云、私有云、PaaS 或非云环境中，并且它将在所有环境中以统一的方式运行。 53 | 54 | 事件网格的动态特性（3）可能是其最重要的属性。 所谓动态，我指的是它能够动态地了解哪些事件将被路由到哪些消费者应用程序，然后在事件发生时实时路由这些事件，无论生产者和消费者在哪里被附加到网格， 而且无需配置事件路由。 我们应该让事件网格负责这些，而不是开发人员。 55 | 56 | ## 为什么企业需要 Event Mesh? 57 | 58 | 简而言之，事件网格支持以下使用场景： 59 | 60 | - 连接和编排微服务 61 | - 将事件从内部部署推送到云应用程序或服务（混合云） 62 | - 跨 LOB(line-of-business) 启用“数据即服务” 63 | - 实现与后端系统的物联网连接 64 | 65 | 这是更长的答案： 66 | 67 | 事件网格使企业能够支持事件驱动的体系结构，从最小的微服务部署，到以易管理、健壮、安全和架构良好的方式将应用程序扩展到混合云。 它提供了动态和全部实时地集成遗留应用程序、数据存储、现代微服务、SaaS、物联网和移动设备的能力。 事件网格为应用程序开发人员和架构师提供了构建和部署分布式事件驱动应用程序的基础，无论他们需要在何处构建和部署。 68 | 69 | ## 结论 70 | 71 | 事件网格概念旨在实现和支持企业数字化转型。 在 2018 年，那些不完全采用事件驱动架构的企业正在向全面拥抱事件驱动架构转型。 但根据我的经验，许多人正在针对特定用例进行此操作，并且通常采用零碎的方法，而不是采用企业范围内事件分发的明确愿景。 72 | 73 | 我相信事件将成为现代企业的生命线。 为此，他们需要让事件在数字企业越来越分散的环境和组件中自由轻松地流动。 74 | 75 | 事件网格就是实现此功能的架构层。 76 | -------------------------------------------------------------------------------- /2018/11/why-is-service-mesh/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://medium.com/@tak2siva/why-is-service-mesh-8ebcd6ed9eb5 3 | translator: zhanye 4 | reviewer: 5 | title: "为什么要选择Service Mesh？" 6 | description: "本文讲述互联网应用演进过程，ServiceMesh能带来什么好处" 7 | categories: "译文" 8 | tags: ["Dokcer","MicroServices","Kubernetes","Monitoring"] 9 | date: 2018-11-08 10 | --- 11 | 12 | ## 为什么要使用Service Mesh 13 | 除非你长期与世隔绝，否则你应该听说过Kubernetes，他已经称为高速发展的互联网公司的一条准则。最近又有一个热门话题--Service Mesh（服务网格），它已经被这些高速发展公司用来解决一些特定的问题。所以如果你想了解什么是Service Mesh，接下来我可以给你一个更好的解释。 14 | 15 | ![](http://ww1.sinaimg.cn/mw690/7267315bgy1fx0r3hzbzlj20zk0ilnmj.jpg) 16 | 17 | ### 互联网应用的演进 18 | 为了理解Sevice Mesh的重要性，我们通过四个阶段来简短的回顾下互联网应用的发展历程。 19 | 20 | #### 阶段0：单体应用 21 | 22 | ![](http://ww1.sinaimg.cn/mw690/7267315bgy1fx0r9265r7j208s06omxs.jpg) 23 | 24 | 还记得那些年吗？所有的代码库都打包成一个可执行和部署的软件包。当然，至今在某些使用场景下这个方式依然是很管用的。但是对于一些业务快速增长的互联网公司，在应用的可扩展性、快速部署和所有权等方面遇到了阻力。 25 | 26 | #### 阶段1：微服务 27 | 微服务的思思想很简单，依照SLA（服务等级协议）将单体应用拆分成多个模块。这种方式运行效果显著，所以广泛为企业所接受。现在，每个团队都用他们喜爱的语言、框架等自由地设计他们的微服务。然后它开始看起来就像下面这样。 28 | 29 | ![](http://ww1.sinaimg.cn/mw690/7267315bgy1fx0si4ef85j218g0n4tde.jpg) 30 | 31 | 我们曾经在我的一个项目中开玩笑说，那里有各种语言的微服务:) 32 | 33 | 尽管微服务解决了单体应用的一些问题，但现在公司有一些严重问题。 34 | 35 | * 为每个微服务定义VM（虚拟机）规范 36 | * 维护系统级别依赖操作系统版本、自动化工具（如chef）等 37 | * 监控每个服务 38 | 39 | 对负责构建和部署的人来说这就是一个噩梦。 40 | 41 | ![](http://ww1.sinaimg.cn/mw690/7267315bgy1fx0vg3ks7aj20dc07iq53.jpg) 42 | 43 | 而且这些服务在虚拟机中共享同一个OS，但为了达到可移植性，服务之间需要隔离或者被封装到独立的VM镜像。微服务典型的架构设计如下图所示： 44 | 45 | ![](http://ww1.sinaimg.cn/mw690/7267315bgy1fx0vt7d9woj218g0n4tc3.jpg) 46 | 47 | 但为每个服务/副本安装在一台独立的虚拟机上，花费是非常高的。 48 | 49 | #### 阶段2：容器化 50 | 51 | 容器是利用Linux中的 [cgroups](https://en.wikipedia.org/wiki/Cgroups) 和 [namespace]( https://en.wikipedia.org/wiki/Linux_namespaces) 的一种新的操作系统级别的虚拟化技术，通过共享主机的操作系统，实现为不同的应用隔离运行环境的。Docker是目前最流行的容器运行时。 52 | 53 | 所以我们会为每个微服务创建一个容器镜像并以容器形式发布成服务。这样不仅可以在一个操作系统上实现应用运行环境的隔离，而且启动新的容器相比于启动新的VM速度更快、成本也更低！使用容器技术之后的微服务设计看起来就像这样。 54 | ![](http://ww1.sinaimg.cn/mw690/7267315bgy1fx0wzyguoej218g0n4ju8.jpg) 55 | 容器化解决了构建和部署的问题，但还没有完美的监控解决方案！那要怎么办？我们还有其他问题吗？管理容器！ 56 | 57 | 使用容器运行一个可靠的基础设施层需要注意以下几个重要的点： 58 | * 容器的可用性 59 | * 生成容器 60 | * 扩容/缩容 61 | * 负载均衡 62 | * 服务发现 63 | * 调度容器到多个主机 64 | 65 | 66 | #### 阶段3：容器编排 67 | ![](http://ww1.sinaimg.cn/mw690/7267315bgy1fx1kwi5nvpj205t05o74e.jpg) 68 | 69 | Kubernetes是当下最流行的容器编排工具，它彻底改变了我们对基础设施的看法。Kubernetes侧重于健康检查，可用性，负载均衡，服务发现，扩展性，跨主机调度容器等等，很神奇！ 70 | 71 | 我们要的就是这样吗？ 72 | 73 | 并不完全是，仅仅这样还不能解决在微服务阶段提到的服务监控/观测的问题。这只是冰山一角。微服务是分布式的，所以管理微服务不是件容易的事。 74 | 75 | 我们需要考虑一些最佳实践来便捷地运行微服务。 76 | 77 | * Metrics（延迟，成功率等） 78 | * 分布式链路追踪 79 | * 客户端负载均衡 80 | * 熔断 81 | * 流量迁移 82 | * 限速 83 | * 访问日志 84 | 85 | 像Netflix这样的公司已经推出了几种工具，并接受了那些运行微服务的做法。 86 | 87 | * Netflix Spectator（Metrics） 88 | * Netflix Ribbon（客户端负载均衡/服务发现） 89 | * Netflix Hystrix（熔断器） 90 | * Netflix Zuul（边界路由） 91 | 92 | 现在，为了满足这些最佳实践的唯一方法是在每个微服务上使用一个客户端库来解决每个问题。所以每个服务的结构看起来就像这样。 93 | ![](http://ww1.sinaimg.cn/mw690/7267315bgy1fx1ojjkrfuj212g0fymz5.jpg) 94 | 但这是针对像Service A这样的用JAVA写的服务，那其他的服务要怎么办？ 95 | 如果我使用其他语言没有类似java的库要怎么办？ 96 | 怎样才能让所有团队使用/维护/升级库版本？ 97 | 我们公司有上百个服务，我要修改所有应用都使用上面的库吗？ 98 | 99 | 发现了吗？自微服务诞生以来，这些一直都是个问题（语言限制、应用代码改造）。 100 | 101 | #### 阶段4：服务网格 102 | 目前有多种代理为Service Mesh提供解决方案，如：[Envoy](https://www.envoyproxy.io/)、Linkerd和Nginx。本文只关注Envoy的Service Mesh。 103 | 104 | Envoy是针对微服务产生的这些问题设计出来的服务代理。 105 | 106 | Envoy能够作为 [SideCar](https://docs.microsoft.com/en-us/azure/architecture/patterns/sidecar) 运行在每个应用的旁边，形成抽象的应用网络。当基础设施中的所有服务流量通过Envoy网格流动时，通过一致的可观察性来问题区域变得容易。 107 | 108 | 如下图所示，当把Envoy作为SideCar添加到服务后，所有微服务的入站和出站流量都通过各自的Envoy代理 109 | ![](http://ww1.sinaimg.cn/mw690/7267315bgy1fx1t3tisq1j218g0n4q5x.jpg) 110 | 111 | Envoy拥有许多方便的功能 112 | * 支持HTTP,HTTP/2和gRPC 113 | * 健康检查 114 | * 负载均衡 115 | * Metrics 116 | * 追踪 117 | * 访问日志 118 | * 熔断 119 | * 重试策略 120 | * 超时配置 121 | * 限速 122 | * 支持Statsd、Prometheus 123 | * 流量迁移 124 | * 通过发现服务来动态调整配置（XDS） 125 | 等…… 126 | 127 | 所以通过从服务中抽象出整个网络，使用Envoy作为SideCar形成网格组成数据平面，允许我们控制上面列出的能力。 128 | 129 | 欢迎反馈，谢谢！ 130 | 131 | -------------------------------------------------------------------------------- /2018/12/from-fragmented-microservices-ecosystem-to-service-mesh/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://blog.avinetworks.com/from-fragmented-microservices-ecosystem-to-service-mesh 3 | author: Manish Chugtu 4 | translator: DavadDi 5 | reviewer: rootsongjc 6 | title: "从百家争鸣的微服务生态到服务网格" 7 | description: "从百家争鸣的微服务生态到服务网格" 8 | categories: "translation" 9 | tags: ["Microservice","Service Mesh"] 10 | date: 2018-12-13 11 | --- 12 | 13 | # 从百家争鸣的微服务生态到服务网格 14 | 15 | 在过去几年中，我们注意到应用程序架构正在迅速转变为分布式微服务架构——单体和庞大的应用程序被分解为更小的单个服务，其可被独立修改、构建、部署和管理。这种模式的主要优点就是简洁和快速，同时由于其对其他服务的依赖性很小或者完全没有依赖，更易于升级和独立扩展。这与敏捷和DevOps理念非常吻合，这种模式也已经被许多规模化的Web公司成功采用。过去的许多年中，这些公司中的大多数都能够很好地采用这种模式，但是近几年中成功将这种模式发扬光大的两大推手非Docker和Kubernetes莫属。Docker简化了将微服务构建为Linux容器的过程，Kubernetes则能够以资源优化的方式来部署、管理和扩展服务。 16 | 17 | ## 应用架构演进 18 | 19 | 在这篇博客中，我们不会花太多时间讨论微服务架构的优缺点。相反，我们将专注于在向基于微服务构建的云原生架构的重大转变上。 20 | 21 | 虽然微服务架构提供了灵活性，但其也带有复杂性。Kubernetes在部署和管理微服务方面发挥了非常重要的作用，但我们需要的不仅仅是单一的运行在生产环境中的云原生应用程序——还需要在服务发现、安全性、流量管理等方面需要更加深入的了解。尤其是在相互通信的成千上百个服务经常被删除、生产、扩展和更新的复杂环境下，深入的了解更加有必要性。 22 | 23 | ![img](https://wx3.sinaimg.cn/mw1024/7e0ee03agy1fy53fs6ze4j20qf0b9gnq.jpg) 24 | 25 | ## 微服务架构面临的挑战 26 | 27 | 这种规模化和动态化对于早期运行单体程序和管理应用程序的基础设施带来了具体的转变。为支持这种动态环境，新一代架构需要在生态系统中补充大量的新技术。为了交付所有的用户场景，我们需要在基础架构栈的每个级别上提供多个解决方案。根据需要，基础架构人员开始将这些技术集成到平台上，但这也意味着程序开发人员需要额外的负担来支持这些技术。 28 | 29 | ![img](https://wx2.sinaimg.cn/mw1024/7e0ee03agy1fy53fsh5iej20rd0cejup.jpg) 30 | 31 | ## 基础架构栈高层视图 32 | 33 | 这不是人们所期望的，并且也绝对不是微服务架构做出的的敏捷性、易于开发和部署的承诺。 34 | 35 | 此后出现了服务网格的理念，这也是Avi Networks在此术语被创造之前一直专注于为客户提供的内容，并且由Istio和Linkerd等开源项目推动下形成了事实上的标准。我们很高兴看到社区热情拥抱了服务网格，而且我们也认为服务网格是微服务基础架构的必要组成部分。 36 | 37 | 那么什么是 “服务网格” ，其如何帮助解决这些问题的呢？服务网格实质上是提供了上面图中在基础架构中的多层服务，与此同时程序开发者无需集成或修改代码就可以利用这些服务。它不仅使服务之间的通信快速可靠，而且服务网络还提供细粒度的流量管理、故障恢复、安全（加密、授权和认证）和可观察性（如跟踪、日志和监控）。所有这些都是从使用某种架构的开发人员中抽象出来的，其中所有服务间的通信都流经sidecar代理，代理与每个服务一起部署，从而创建一个服务网格。Sidecar由集中控制平面管理配置，用于流量路由和策略实施。尽管运行与应用程序容器一样多的sidecar容器一直是争论的焦点，但服务网格的优势和功能似乎超过了运维问题。 38 | 39 | 在本博客系列的其余部分，我将深入探讨如何实现服务网格，并使用Istio的参考架构来完成旅程，因为Istio是当前最广泛使用和最知名的服务网格解决方案之一。但Istio是否解决了所有问题，并且在处理当今微服务世界中存在的重要场景方面是否完整？我们将深入探讨这一点，并在本系列的后续部分讨论所有内容。 敬请关注！ 40 | 41 | Manish Chugtu - CTO Cloud Infrastructure和Microservices@Avi Networks，是一位创新思想领军人物，在架构，设计和产品开发方面拥有 18 年以上的经验，在架构和开发高度可扩展的企业解决方案方面拥有丰富的经验。目前，他致力于推动Avi在容器和云基础架构领域的战略， [他的 LinkedIn](https://www.linkedin.com/in/manishchugtu/)。 42 | -------------------------------------------------------------------------------- /2019/01/istio-kubernetes-service-mesh/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://blog.aquasec.com/istio-kubernetes-service-mesh 3 | author: "Luke Bond" 4 | translator: "saberuster" 5 | reviewer: ["rootsongjc"] 6 | title: "企业级微服务解决方案：Istio" 7 | description: "本文介绍了什么是Istio，并详细分析了Istio的优势，最后分享了关于Istio的一些落地经验。" 8 | categories: "translation" 9 | tags: ["istio", "microservices"] 10 | date: 2018-09-28 11 | --- 12 | 13 | 2017年5月，谷歌面向大规模容器化应用管理的开源项目Istio正式发布了。此后经过快速的发展，于2018年7月发布了里程碑式的1.0版本。本文的主要内容包括：Istio是什么、Istio的工作原理以及落地方式。在本系列的后续文章中我们还会深入了解Istio的安全和流量管理功能。 14 | 15 | #### Istio是什么？ 16 | 17 | 从过去几年发布的大量开源项目中我们可以总结出谷歌内部构建、部署与管理大型分布式容器化应用的方案。而Istio就是这个方案的最后一步——管理应用程序。了解Istio在谷歌内部的起源可以帮你更好的理解它的设计思想和历史背景。 18 | 19 | Netflix详细的介绍过混沌工程实践以及故障注入、熔断、限流和链路跟踪等概念。为了避免在每个新项目中都需要重新实现这些功能，开发者一般选择在底层网络实现它们。当前的两种嵌入方式： 20 | 21 | 1. 把这些功能和公司用到的所有语言的网络库打包到一起，并为所有的服务和团队维护它们。 22 | 23 | ![](http://ww1.sinaimg.cn/large/005UD0i6ly1fzodfkzee3j30go09s3yt.jpg) 24 | 25 | 2. 通过服务网格透明的提供这些功能。Istio使用的就是这种方式。Istio把[Envoy代理](https://www.envoyproxy.io/)作为每个pod的sidecar运行并通过Istio的控制平面来动态的配置Envoy从而实现这些功能。具体如下图所示: 26 | 27 | ![](http://ww1.sinaimg.cn/large/005UD0i6ly1fzodgf1rjpj30en0a43yv.jpg) 28 | 29 | 利用基于Envoy的sidecar机制，Istio无需修改应用代码就可以完成嵌入。Envoy代理容器的所有网络流量，而Istio的控制平面可以动态配置Envoy的策略。因此Istio可以在对应用透明的前提下提供诸如TLS双向验证、限流和熔断等功能。 30 | 31 | Istio不仅仅是服务网格的解决方案，它还包含另外一个关键概念：服务认证。就像系统通过用户认证来验证用户身份一样，服务也可以像用户一样做认证。我们可以在服务之间建立基于角色的访问控制（RBAC），还能更细粒度的规范服务在网络中的行为。 32 | 33 | 虽然Istio可以在VM上运行，也可以在Kubernetes集群和VM上扩展，但我们还是主要讨论在Kubernetes环境下的Istio。 34 | 35 | #### Istio的优势 36 | 37 | - **开箱即用的微服务遥测** 微服务能够通过Istio自动生成遥测平面，无需额外工具就能生成统一的应用指标数据和链路追踪数据。 38 | - **双向TLS** Istio可以在不修改应用的前提下，为服务间调用配置双向TLS认证。 集群内的CA能够为Envoy代理提供必要的证书以保护服务间的流量。 39 | - **红黑部署** 通过在部署期间动态分配应用程序的新老版本之间的流量，我们可以一边观察集群的报错情况，一边将新版本应用逐渐部署到生产环境。 40 | - **丰富的网络策略** 使用Kubernetes我们可以为它的API接口和服务间的网络策略提供RBAC认证。而Istio不仅可以做RBAC认证，它的认证粒度还能限制到HTTP协议的方法和资源路径。 41 | 42 | 应用开发者能够专注于在7层网络的商业价值而不用浪费时间为基础设施编写重复的解决方案。 43 | 44 | #### Istio架构 45 | 46 | Istio由数个管理组件的控制平面和控制平面控制的与Envoy sidecar一起运行的服务集合构成。控制平面由以下几个组件组成： 47 | 48 | - **Pilot:** 管理和维护所有的Envoy代理中的各种路由规则和RBAC配置。 49 | - **Mixer:** 进行遥测数据采集和执行访问控制/使用策略。 50 | - **Citadel:** 负责颁发和更新TLS证书。 51 | - **Galley:** 它和用户关系不大，主要负责收集和验证系统其他组件的用户配置。 52 | - **Proxy:** Envoy作为每个Kubernetes pod的sidecar代理运行可以提供动态服务发现，负载均衡，TLS认证，RBAC，HTTP和gRPC代理，熔断，健康检查，滚动更新，故障注入和遥测数据。 53 | - **Gateway:** 网关可以作为集群ingress或egress的负载均衡边缘代理。ingress规则可以通过路由规则进行配置。 54 | 55 | #### 落地Istio过程中的经验 56 | 57 | 虽然使用Istio能带来立竿见影的好效果，但要想将它的优势发挥到最大，还必须要有设计良好的微服务架构。好的微服务系统，应该是由多个团队维护的多个小服务。所以它需要团队和业务进行转型，而这点往往容易被忽略。 58 | 59 | 如之前所说，不管您的应用程序的设计或成熟度如何，都能从Istio中获益。 60 | 61 | 提高可观察性有助于解决微服务设计中的问题。在迁移、重构或整合项目时使用Istio是有好处的，而在设计良好的微服务项目环境中使用，会让Istio大放异彩。 但请记住，增加任何组件都会增加系统的复杂度。 62 | 63 | 安装Istio包括安装控制平面组件和配置Kubernetes的pod将所有流量由Envoy代理两步组成。Istio的命令行工具*istioctl*的[*kube-inject*](https://www.aquasec.com/about-us/careers/)命令可以在部署时修改你的YAML配置来给pod增加Envoy代理。另一种使用Istio的方式就是[*webhook admission controller*](https://kubernetes.io/docs/admin/admission-controllers)，它可以在部署时自动的添加Envoy代理，你可以在应用完全无感知的情况下获得Istio的所有好处。 64 | 65 | 我推荐先装不含任何功能的Istio，然后将各个功能逐渐的用起来，一次做的太多调试起来会比较麻烦。就像Istio团队在推广时所说："Istio是个菜谱"，你不需要一下就把Istio全部用起来。 据以往的经验，从默认的遥测功能开始使用Istio是个不错的选择。 66 | 67 | #### Istio安全性 68 | 69 | Istio真正的亮点是服务认证，RBAC认证和端到端的双向TLS认证。在本系列的后续文章会详细介绍这方面内容。 70 | 71 | #### 总结 72 | 73 | Istio区别于Hystrix，它采用服务网格的设计方案。因此落地和运维都变得更加简单。Istio为服务无感知的增加了流量控制和安全性，如果想发挥它的最大效益，还需要设计良好的微服务架构。即使是非常老旧的项目也能在Istio的遥测技术和安全性上获益。 -------------------------------------------------------------------------------- /2019/02/faas-vs-microservices/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | author: Christian Posta 3 | title: "选择FaaS还是微服务？" 4 | translator: "saberuster" 5 | reviewers: ["haiker2011","wujunze"] 6 | description: "本文主要向读者介绍FaaS和微服务架构之间的区别以及如何根据自身情况选择正确的架构方案。" 7 | categories: "译文" 8 | tags: ["FaaS", "microservice", "serverless"] 9 | date: 2018-12-17 10 | --- 11 | 12 | 在做项目的云原生改造时我们可以采用微服务架构。DevOps和自动化构建两方面的成功经验对微服务的实践很有帮助。经过一段时间的实践，你可能会有将微服务架构推广到其他部门的想法。而你担心微服务本身的复杂性和分布式系统的高维护成本会让其他部门难以接受它。可能在我们想方设法解决微服务带来的问题时，总会有些人觉得这样做毫无意义。因为现在技术发展如此之快，总会出现更好的技术方案，你能保证自己在微服务领域所做的工作最后没有白费吗？ 13 | 14 | 我认为不会白费！ 15 | 16 | 现在“serverless”和“functions-as-a-service”（FAAS）还处于早期的炒作阶段。有些人觉得serverless就是下一代的微服务，所以我们应该跳过当前的微服务模式而直接采用serverless。其实这种说法是有点夸大其词。作为架构师或开发者，我们通过学习新技术来提升自身能力让自己变得更"值钱"并没有错。但我们也要以务实态度来判断是否应该采用新技术。虽然持续跟进最新技术是我们作为架构师的职责所在，但掌握在之前的产品和IT部门引用新技术的时机也很重要。我们可以通过下面的模块来理解微服务架构和serverless，从而让它们可以更好的融入我们的技术栈。 17 | 18 | 首先，我们需要知道为什么我们需要微服务。选用微服务架构的主要原因就是避免项目的体量阻碍产品的迭代，所有微服务其他的优势都是基于这点。更快的迭代速度意味着可以更快的为客户交付新功能/修改，从而更快的验证这些改动能够带来的效果。我们需要快速的知道自己所做的努力是否能够带来好的效果，如果不能就要马上调整方向。快速迭代就是微服务架构的核心优势。 19 | 20 | 对于大多数的团队而言，至少有一部分应用能从微服务的迭代过程中获益。因此作为架构师或开发者，我们不要因为采用微服务有门槛就对其失去信心。实践微服务的重要步骤就是确定和测量改进指标。改进指标一般可以为每天迭代应用的次数、保证迭代应用稳定性的方法等。 21 | 22 | 另一方面，不是所有的应用都需要用这种松散而复杂的方式来保证服务的迭代速度。如果只想简单做个应用来验证自己创意的商业价值，那你完全可以选择更加适合的架构。这时采用MVP测试（最小可行性测试）就是个很好的方案。如果你因为商业价值很低而打算放弃的话，那也只是放弃了一个MVP应用。你可以非常快的迭代它并从潜在的用户中获得反馈。在这种情况下，你可能需要根据反馈反复修改API、功能边界、组件等。所以过早就将组件功能做成分布式的服务也会拖慢产品的发布速度。你想修改分布式组件和它的api就必须在各个团队间进行协调。 23 | 24 | 上述观点能够反映出微服务架构和单体架构适用不同的场景。而事实上并没有所谓"一招鲜吃遍天“的方案。当我们在微服务架构和单体架构之间纠结时，还需要考虑到所需服务是否已经存在以及它提供服务的方式（第三方服务/公司内部服务）。我们完全可以充分利用当前已有服务来构建我们的应用，不必重新购买硬件、安装和修补操作系统，以及优化服务从而达到最高吞吐量，而这也正是云及其服务存在的意义。云供应商和他们的合作伙伴能提供数据库、消息队列、缓存、CDN和其他更高级的功能： 例如语言翻译、地图/地理空间地图、天气等。我们可以组合各种按量付费的服务来构建自己的应用。如果在使用某个服务的时候无需关心安装、参数和容量等问题，其实我们就已经在采用serverless架构了。serverless架构的特点就是可以重用已经存在的service，而无需关心运行服务需要消耗些什么。 25 | 26 | 函数即服务和serverless具有某种联系，因为它利用了缩小到单个应用程序函数的范围的计算模型，而这有助于将各种服务组合在一起构建应用。在这种模型下，功能按需分解，你只需为使用的功能付费。它特别适合对我们使用的服务进行按需计费和按量付费。这样一来我们能够构建弹性应用，而不需要考虑复杂的技术问题。将这些复杂的技术问题外包给别人可以让你更专注于为客户提供商业价值。 27 | 28 | 但是将这部分能力外包不总是可行的。如果选择云服务，我们就丧失了对程序运行时、具体功能、bug修复和接受监管的控制力。这也是需要考虑的一部分。 29 | 30 | serverless不一定是完整的“公有云或无云”方案。如果以单个组织的角度来看，"serverless"可能只是代表整个体系的其他部分。例如：零售业务可以为组织内部其他服务或第三方提供“购买“服务以支持诸如分析、推荐以及其他使用“购买”服务的应用。利用定义良好的API和订阅并消费API的工作负载，你可以在自己的基础设施为微服务应用或单体应用提供serverless能力。在很多时候这其实就是服务向SOA架构进化的方向。但它们之间最大的不同就是在你将组织看作一个整体时，自己给自己的其他部分提供服务并不算serverless。因为此时还是需要自己手动的去安装、管理和更新应用。 31 | 32 | 最终采用哪种方案其实取决于很多因素，例如：业务、商业目标、软件部门对该技术的熟练度和历史遗留问题等。如果你觉得应该采用微服务架构，那就不要因为其他新技术而分心。我们可以持续跟进最新技术，从而保证适时的采用它们。总的来讲，不管是微服务架构、单体架构还是serverless架构，它们都有自己的应用场景。 33 | 34 | -------------------------------------------------------------------------------- /2019/03/application-metrics-in-istio/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://meteatamel.wordpress.com/2019/01/07/application-metrics-in-istio/ 3 | author: "Mete Atamel" 4 | translator: "SataQiu" 5 | reviewer: ["rootsongjc"] 6 | title: "Istio中的应用程序指标度量" 7 | description: "本文介绍了在Istio环境下进行应用程序指标度量的背景知识、一般方法以及可能出现的问题。" 8 | categories: "translation" 9 | tags: ["istio", "metric"] 10 | originalPublishDate: 2019-01-07 11 | publishDate: 2019-03-06 12 | --- 13 | 14 | ## 背景 15 | 16 | Istio发送的默认指标有助于了解流量如何在集群中流动。但是，要了解应用程序的行为，还需要应用程序指标。 17 | 18 | [Prometheus](https://prometheus.io/)提供了[客户端库](https://prometheus.io/docs/instrumenting/clientlibs/)，您可以使用它来检测应用程序并发送监测指标。 19 | 这很好，但也提出了一些问题： 20 | 21 | - 您从哪里抓取这些指标？ 22 | - 您是使用Istio附带的Prometheus，还是自建新的Prometheus？ 23 | - 如果使用Istio附带的Prometheus，那您需要使用什么样的配置来获取这些指标？ 24 | 25 | 让我们尝试回答这些问题。 26 | 27 | ## Istio的Prometheus vs. 独立的Prometheus 28 | 29 | 在Prometheus中，有一个[联邦](https://prometheus.io/docs/prometheus/latest/federation/)功能，它允许一个Prometheus服务端从另一个Prometheus服务端获取指标数据。如果您想将Istio指标和应用程序指标分开，可以为应用程序指标设置一个单独的Prometheus服务端。然后，您可以使用联邦功能来获取应用程序指标以及Istio默认的观测指标。 30 | 31 | 一种更简单的方法是直接使用Istio的Prometheus来提取应用程序的指标，这正是我在这里要重点讨论的。 32 | 33 | ## 发送应用程序指标 34 | 35 | 要从应用程序发送自定义指标，您需要使用Prometheus的[客户端库](https://prometheus.io/docs/instrumenting/clientlibs/)来检测应用程序。使用哪个库取决于您使用的语言。作为C#/.NET开发人员，我使用了Prometheus的[.NET客户端](https://github.com/prometheus-net/prometheus-net)，Daniel Oliver的[这篇博客](https://www.olivercoding.com/2018-07-22-prometheus-dotnetcore/)分步说明了如何从[ASP.NET](http://asp.net/) Core应用程序发送自定义指标并在本地Prometheus服务端查看它们。 36 | 37 | 您需要注意的一件事是开放Prometheus指标的端口。在[ASP.NET](http://asp.net/) Core中，默认开放的端口是5000。在本地执行时，应用程序度量指标暴露于`localhost:5000/metrics`。然而，当您容器化您的应用程序时，通常会在不同的端口开放您的应用程序服务，例如8080，稍后我们讨论配置时，这就变得相关了。 38 | 39 | 假设您在一个启用Istio的Kubernetes集群上容器化并部署了您的应用程序，现在让我们看看需要做些什么来让Istio的Prometheus获取这些应用程序指标。 40 | 41 | ## 配置 42 | 43 | 在Istio 1.0.5中，Kubernetes默认安装文件`istio-demo.yaml`或`istio-demo-auth.yaml`已经在ConfigMap中为Prometheus提供了指标采集配置。您可以搜索`prometheus.yml`。这里有两个与应用程序指标抓取相关的任务配置： 44 | 45 | ```yaml 46 | - job_name: 'kubernetes-pods' 47 | kubernetes_sd_configs: 48 | - role: pod 49 | ... 50 | - job_name: 'kubernetes-pods-istio-secure' 51 | scheme: https 52 | ``` 53 | 54 | 这些是从常规Pod以及启用了mTLS的Pod间抓取指标的任务配置。看起来，Istio的Prometheus应该能够自动地抓取应用程序指标。但是，在我首次尝试时，它并没有正常工作。我不确定出了什么问题，但Prometheus有一些默认endpoint端点： 55 | 56 | - `/config`：查看Prometheus的当前配置。 57 | - `/metrics`：查看抓取的指标数据。 58 | - `/targets`：查看正在被抓取指标的目标以及它们的状态。 59 | 60 | 所有这些endpoint端点对于调试Prometheus非常有用： 61 | 62 | ![](http://ww1.sinaimg.cn/large/007uElTfly1g0s0xtqjpzj30l40cbtaw.jpg) 63 | 64 | 原来，我需要在我的Pod YAML中添加一些注解，以便Prometheus对它们进行指标抓取。我必须通过这些注解告诉Prometheus哪些Pod需要被抓取指标数据，以及在哪个端口进行抓取： 65 | 66 | ```yaml 67 | kind: Deployment 68 | metadata: 69 | name: aspnetcore-v4 70 | spec: 71 | replicas: 1 72 | template: 73 | metadata: 74 | labels: 75 | app: aspnetcore 76 | version: v4 77 | annotations: 78 | prometheus.io/scrape: "true" 79 | prometheus.io/port: "8080" 80 | ``` 81 | 82 | 添加注解后，我能够在Prometheus中看到我的应用程序的指标数据： 83 | 84 | ![](http://ww1.sinaimg.cn/large/007uElTfgy1g0sblvrx4tj30l409p74t.jpg) 85 | 86 | 然而，这只适用于常规Pod，我无法看到启用了mTLS的Pod间的指标数据。 87 | 88 | ## Istio证书和Prometheus的问题 89 | 90 | 经过一番调查后，我联系了Istio团队，结果发现这是个[Bug](https://github.com/istio/istio/issues/10528)。在Prometheus启动时，它将尝试挂载Istio提供的证书。然而，这些证书此时可能还没有被Istio Citadel颁发。不幸的是，Prometheus不会重试加载证书，这导致抓取受mTLS保护的endpoint端点会产生问题。 91 | 92 | 这里有一个不是十分理想，但是却很容易的解决办法：重新启动Prometheus Pod。重新启动迫使Prometheus获取证书，而且来自启用了mTLS的Pod的应用程序指标也开始被抓取。 93 | 94 | ## 结论 95 | 96 | 一旦理解了基础知识，获取Istio Prometheus的应用程序指标就非常简单了。希望这篇文章为您提供了实现这一目标所需的背景知识以及需要的配置说明。 97 | 98 | 值得注意的是，Mixer正在被重新设计，并且在未来版本的Istio中，它将直接嵌入Envoy。 在该设计中，您将能够通过Mixer发送应用程序指标数据，并且它将流经与sidecar相同的统一指标处理管道。 这将使应用程序指标的获取能够更容易地实现端到端工作。 99 | 100 | 感谢Istio团队和我的同事Sandeep Dinesh帮助我调试问题，多亏了他们，我才能完成本文。 -------------------------------------------------------------------------------- /2019/03/do-i-need-a-service-mesh/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://www.nginx.com/blog/do-i-need-a-service-mesh/ 3 | author: "Owen Garrett" 4 | translator: "malphi" 5 | reviewer: ["fleeto","haiker2011"] 6 | title: "我需要服务网格吗？" 7 | description: "本文对当前的服务网格发展状况进行了分析和预测，建议在适当的时机开始使用服务网格来替代现有解决方案。" 8 | categories: "translation" 9 | tags: ["service mesh"] 10 | originalPublishDate: 2019-03-13 11 | publishDate: 2019-04-01 12 | --- 13 | 14 | # 我真的需要服务网格吗？ 15 | 16 | “服务网格”是一个热点话题。似乎去年每一个与容器相关的大会都包含了一个“服务网格”议题，世界各地有影响力的业内人士都在谈论这项革命性的技术带来的好处。 17 | 18 | 然而，截至2019年初，服务网格技术仍不成熟。主要的实现产品Istio还没有准备好进行广泛的企业级部署，只有少数成功的案例运行在生产环境中。也存在其他的服务网格产品，但并没有得到业界专家所说的广泛关注。 19 | 20 | 我们如何协调这种不匹配呢？一方面，我们听到“你需要一个服务网格”的声音，而另一方面，企业和公司多年来一直在没有服务网格的容器平台上成功地运行着它们的应用。 21 | 22 | ## 开始使用 Kubernetes 23 | 24 | *服务网格是你旅途中的一个里程碑，但它不是起点。* 25 | 26 | 在容器应用的生产环境部署中，Kubernetes已经被证明是一个可以胜任的平台。它提供了一个丰富的网络层，提供了[服务发现](https://kubernetes.io/docs/concepts/services-networking/service/#discovering-services)， [负载均衡](https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies)， [健康检查](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes) 和[访问控制](https://kubernetes.io/docs/concepts/services-networking/network-policies/) 的能力，以支持复杂的分布式系统。 27 | 28 | 这些功能对于简单和易于理解的应用程序来说已经足够了， [遗留的应用已经被容器化](https://www.docker.com/solutions/MTA)。 它们允许你满怀信心地部署应用，根据需要扩容，避免意外故障，并实现简单的访问控制。 29 | 30 | ![1](https://ws1.sinaimg.cn/large/006tKfTcly1g1byouk0a6j30sg0da3zi.jpg)① Kubernetes 提供了带有服务发现和负载均衡的4层网络。② NGINX入口控制器负责把外部连接负载均衡到运行在Kubernetes集群的服务。 31 | 32 | Kubernetes在它的API中提供了一个入口（Ingress）资源对象。 这一对象定义了如何选择可以被集群外部访问的服务，一个入口控制器实现了那些策略。 NGINX作为大多数实现中负载均衡的选择，我们为开源的NGINX和NINGX Plus都提供了[高性能、可支持的、生成环境的实现](https://www.nginx.com/products/nginx/kubernetes-ingress-controller/)。 33 | 34 | 对很多线上应用而言，Kubernetes和入口控制器提供了所有需要的功能，不需要任何更复杂的演进。 35 | 36 | ## 下一步：更复杂的应用 37 | 38 | *添加安全，监控和流量管理来提升控制和可视化。* 39 | 40 | 当运维团队管理生产环境中的应用时，有时候需要更深入的控制和可见性。复杂的应用可能会表现出复杂的网络行为，在生产环境频繁的变化会给应用的稳定性和一致性带来更多的风险。在共享的Kubernetes集群上运行时，可能需要加密组件之间的通信。 41 | 42 | 每一项需求都可以使用易于理解的技术来满足： 43 | 44 | - 要保护服务间的通信，你可以使用SPIFFE或等效的方法在每个服务间实现双向TLS。 45 | - 为了识别性能和可靠性的问题，每个微服务可以导出[兼容Prometheus的指标](https://prometheus.io/docs/instrumenting/ters/)，并使用Grafana等工具进行分析。 46 | - 要调试这些问题，可以将[分布式追踪](https://opentracing.io/docs/overview/tracers/)嵌入到每个微服务中（支持多种语言和框架）。 47 | - 为实现高级的负载均衡策略、蓝绿部署、金丝雀发布和熔断器，你可以选择性的部署代理和负载均衡器。 48 | 49 | ![2](https://ws2.sinaimg.cn/large/006tKfTcly1g1d0pnxtybj30sg0brdgp.jpg)独立的微服务可以使用**Prometheus导出器， 分布式追踪器， 双向TLS和SPIEE进行扩展**。代理可以被部署为独立的服务如①，或者像②一样提供中央路由网格。 50 | 51 | 其中一些技术需要对每个服务做一些小的修改——例如，将证书注入到容器中，或者为Prometheus和OpenTracing添加模块。NGINX Plus可以为关键服务提供专用的负载均衡，通过服务发现和API驱动的配置来编排更改。NGINX微服务参考架构中的[Router Mesh](https://www.nginx.com/blog/microservices- Reference - Architecture - NGINX - Router - mes-model/)模式实现了一个集群范围的流量控制点. 52 | 53 | 现在，几乎所有在生产环境中运行的容器化应用都使用类似的技术来提高控制和可见性。 54 | 55 | ## 为什么我还需要一个服务网格？ 56 | 57 | *如果上面的技术在生产环境已经被验证，服务网格增加了什么？* 58 | 59 | 上一节中描述的每个步骤都给应用程序开发人员和运维团队带来了适应它的负担。单独来说，这些负担很轻，因为解决方案很好理解，但是重量会累积。最终，运行大规模、复杂应用的企业组织可能会达到一个临界点，在这个临界点上，提高服务到服务的应用将变得难以扩展。 60 | 61 | 这是服务网格承诺要解决的核心问题。服务网格的目标是以标准化和透明的方式交付所需的功能，对应用透明。 62 | 63 | 服务网格技术仍然是一项新技术，只有很少的生产环境的部署。早期的部署建立在复杂的、自主开发的解决方案之上，具体到每个采用者的需求。一种更为普遍的方法正在出现，称为“sidecar代理”模式。该方法在每个服务实例边部署一个7层代理；这些代理捕获所有的网络流量，并以一致的方式提供额外的功能——双向TLS、追踪、度量、流量控制等。 64 | 65 | ![3](https://ws3.sinaimg.cn/large/006tKfTcly1g1d19j3xxqj30sg0e0wg0.jpg) 66 | 67 | 在服务网格中，每个容器都包含一个嵌入式代理，它拦截所有的进出流量。代理代替服务处理加密、监视和跟踪，并实现高级的流量管理。 68 | 69 | 服务网格技术仍然是一个非常新的技术，供应商和开源项目都急于实现稳定、功能强大且易于操作的产品。2019年几乎肯定会是[“服务网格年”](https://businesscomputingworld.co.uk/t/year-of-service-mesh-what-to-in-2019/1345)，在这个充满希望的技术中，一些实现将真正为通用应用程序的生产环境部署做好准备。 70 | 71 | ## 现在我应该做什么? 72 | 73 | 2019年初，仅在急需短期方案，并且其它解决方案的局限性导致需求无法被满足的情况下，才需要考虑采用仍属早期阶段的服务网格技术。当前服务网格实现的不成熟和快速变化使得部署它们的成本和风险很高。随着技术的成熟，成本和风险将会降低，采用服务网格的时间点将会越来越近。 74 | 75 | ![4](https://ws2.sinaimg.cn/large/006tKfTcly1g1d1iior8kj30sg0fxjs0.jpg)随着应用程序复杂性的增加，服务网格将成为实现服务到服务的能力的现实选择。 76 | 77 | 但是，不要让缺乏稳定成熟的服务网格延误你今天正在考虑的任何计划。正如我们所看到的，Kubernetes和其他编排平台提供了丰富的功能，使得我们可以遵循熟悉的、易于理解的方式来实现复杂的功能。现在继续沿着这些路径前进，使用经过验证的解决方案，如入口路由器和内部负载均衡器。当你到达临界点时，将会知道是时候考虑使用服务网格去实现它们了。 -------------------------------------------------------------------------------- /2019/03/prometheus-monitor-k8s-1/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://xianyuluo.com/post/prometheus%E7%9B%91%E6%8E%A7k8s1.html 3 | author: "xianyuLuo" 4 | reviewer: ["rootsongjc"] 5 | title: "Prometheus监控k8s(一)——监控框架调研" 6 | description: "本文旨在于寻找一套能够胜任kubernetes集群监控的架构" 7 | categories: "原创" 8 | tags: ["prometheus", "kubernetes"] 9 | originalPublishDate: 2019-01-01 10 | publishDate: 2019-03-13 11 | --- 12 | 13 | # 背景 14 | 由于容器化和微服务的大力发展，Kubernetes基本已经统一了容器管理方案，当我们使用Kubernetes来进行容器化管理的时候，全面监控Kubernetes也就成了我们第一个需要探索的问题。我们需要监控kubernetes的ingress、service、deployment、pod......等等服务，以达到随时掌握Kubernetes集群的内部状况。 15 | 16 | 此文章是Prometheus监控系列的第一篇，目的也很明确，旨在于寻找一套能够胜任kubernetes集群监控的架构。 17 | 18 | # k8s监控方案调研 19 | 20 | - [ ] 1、cAdvisor + InfluxDB + Grafana 21 | - [ ] 2、Heapster + InfluxDB + Grafana 22 | - [x] 3、Promethus + kube-state-metrics + Grafana 23 | 24 | - **Grafana**: 25 | 开源DashBoard，后端支持多种数据库，如：Influxdb、Prometheus...，插件也比较多，功能强大。非常适合用于做展示。 26 | 27 | - **InfluxDB**: 28 | 开源时间序列数据库，性能高效 29 | 30 | - **cAdvisor**: 31 | 来自 Google 的容器监控工具，也是 Kubelet 内置的容器资源收集工具。它会自动收集本机容器 CPU、内存、网络和文件系统的资源占用情况，并对外提供 cAdvisor 原生的 API。随 kubelet 启动 --cadvisor-port = 1 32 | 33 | ![cadvisor架构](http://dl-blog.laoxianyu.cn/cadvisor.png) 34 | 35 | - **Heapster**: 36 | 由于 cAdvisor 只提供了单机的容器资源占用情况，而 Heapster 则提供了整个集群的资源监控（kubernetes 1.11 之前，hpa都是从heapster获取数据），并支持持久化数据存储到 InfluxDB 37 | 38 | ![heapster架构](http://dl-blog.laoxianyu.cn/heapster.png) 39 | 40 | - **Promethues**: 41 | 提供强大的数据采集、数据存储、数据展示、告警等，天生完美支持kubernetes，CNCF基金会的第二个成员，第一个是Kubernetes。而且Prometheus里面很多思想都来源于Google内部的监控系统Borgmon，可以说是Google的干儿子。 42 | 43 | ![Prometheus架构](http://dl-blog.laoxianyu.cn/prometheus.png) 44 | 45 | - **kube-state-metrics**在这里作为prometheus的一个exporter来使用，提供deployment、daemonset、cronjob等服务的监控数据，由kubernestes官方提供，与prometheus紧密结合。 46 | 更多关于kube-state-metrics的信息：https://github.com/kubernetes/kube-state-metrics 47 | 48 | # Prometheus优势 49 | #### Prometheus和kubernetes相亲相爱 50 | Google干儿子，大厂维护，而且最重要的一点是完美支持Kubernetes 51 | #### 规范定义 52 | Prometheus对于应用层的监控，定义了一个良好的规范，只需要应用提供接口获取日志就可以了 53 | #### Prometheus可以在各个层面实现监控，如下 54 | - 基础设施层：监控各个主机服务器资源(包括Kubernetes的Node和非Kubernetes的Node)，如CPU,内存,网络吞吐和带宽占用,磁盘I/O和磁盘使用等指标。 55 | - 中间件层：监控独立部署于Kubernetes集群之外的中间件，例如：MySQL、Redis、RabbitMQ、ElasticSearch、Nginx等。 56 | - Kubernetes集群：监控Kubernetes集群本身的关键指标 57 | - Kubernetes集群上部署的应用：监控部署在Kubernetes集群上的应用 58 | 59 | 基于以上三点，所以最终选择使用Prometheus来监控Kubernetes集群。 60 | 61 | # Kubernetes集群监控架构 62 | 63 | 在具体讨论Prometheus监控架构之前，再来看几个实际的问题 64 | 65 | 1. 如果有多个Kubernetes集群，怎么做？ 66 | 67 | 2. 多个Kubernetes集群的监控数据怎么处理？ 68 | 69 | 3. 告警应该怎么集中并去重？ 70 | 71 | 好在这些问题对Prometheus来说都不是难事，最终，我们采取 Prometheus + kube-state-metrics + Alertmanager + Grafana 架构来做Kubernetes集群监控。监控系统具体架构如下 72 | 73 | ![k8s监控架构](http://dl-blog.laoxianyu.cn/prometheus-monitor.png) 74 | 75 | 使用这个架构，那上面所提到的三个问题将不再是问题。 76 | ## 详解 77 | 78 | ### K8s集群： 79 | k8s集群-1/-2/-3为需要被监控的集群，就是业务集群。每个集群内部都部署了一个Prometheus，主要由两部分组成 prometheus-server + kube-state-metrics。 80 | 81 | prometheus-server：使用一个带RBAC权限的账号采集集群中现有监控信息（其实是从cadvisor获取）和节点信息。 82 | 83 | kube-state-metrics：这里作为prometheus的exporter使用。因为prometheus不能获取集群中Deployment, Job, CronJob的监控信息。 84 | 部署kube-state-metrics的时候，svc一定要带一个annotations：prometheus.io/scrape: 'true'（**这非常重要**） 85 | 86 | ### 监控汇总 87 | 监控汇总其实就是一个Prometheus-server，用于将各个散落在各地的监控数据汇总起来，统一管理。 88 | 89 | 核心思想是利用Prometheus的federation机制，从其他集群pull数据。这样其他集群的prometheus只需要短暂存储数据，汇总之后再做长期存储；同时还可以统一做告警判断和数据展示。 90 | 91 | Prometheus官方Federation示例 92 | 93 | ```yaml 94 | - job_name: 'federate' 95 | scrape_interval: 15s 96 | 97 | honor_labels: true 98 | metrics_path: '/federate' 99 | 100 | params: 101 | 'match[]': 102 | - '{job="prometheus"}' 103 | - '{__name__=~"prometheus_job:.*"}' 104 | 105 | static_configs: 106 | - targets: 107 | - 'source-prometheus-1:9090' 108 | - 'source-prometheus-2:9090' 109 | - 'source-prometheus-3:9090' 110 | ``` 111 | 这段配置所属的Prometheus将从source-prometheus-1 ~ 3这3个Prometheus的/federate端点拉取监控数据。 match[]参数指定了只拉取带有job="prometheus"标签的指标，或者名称以prometheus_job开头的指标。 112 | 113 | 114 | ### 展示面板 115 | 展示面板就是一个Grafana，支持使用Prometheus做为数据源进行绘图展示。 116 | 117 | ### 告警处理 118 | 告警是利用Prometheus官方提供的Altermanager模块。Alermanager模块从Prometheus-Server接收告警信息，然后进行汇总、屏蔽、告警...等等操作。Alertmanager告警途径支持有email、wechat、webhook、slack等等，非常丰富。但是这里使用的是自身开发的Send_msg模块。 119 | 120 | ### 消息发送 121 | 自主开发的消息发送模块，集成email、微信、钉钉、短信等方式。其实不止告警时会发送消息，还有其他地方也会用到消息发送。 122 | 123 | 监控架构清楚之后，接下来就是实施监控的一个过程了，具体实施步骤请看“Prometheus系列”第二篇文章。 124 | 125 | # 结束 126 | 此文章也是“使用prometheus完美监控kubernetes集群”系列的第一篇，对文章有不理解的地方，欢迎随时后台留言。 127 | 128 | 129 | -------------------------------------------------------------------------------- /2019/04/automated-canary-deployments-with-flagger-and-istio/0071hauBly1g1u72wr801j30rs0cdq4w.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/automated-canary-deployments-with-flagger-and-istio/0071hauBly1g1u72wr801j30rs0cdq4w.jpg -------------------------------------------------------------------------------- /2019/04/automated-canary-deployments-with-flagger-and-istio/0071hauBly1g1ubacxpukj30rs0mhjvg.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/automated-canary-deployments-with-flagger-and-istio/0071hauBly1g1ubacxpukj30rs0mhjvg.jpg -------------------------------------------------------------------------------- /2019/04/automated-canary-deployments-with-flagger-and-istio/0071hauBly1g1ubdv033ej30rs0ap400.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/automated-canary-deployments-with-flagger-and-istio/0071hauBly1g1ubdv033ej30rs0ap400.jpg -------------------------------------------------------------------------------- /2019/04/automated-canary-deployments-with-flagger-and-istio/0071hauBly1g1uc4hvoo6j30rs05ymy8.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/automated-canary-deployments-with-flagger-and-istio/0071hauBly1g1uc4hvoo6j30rs05ymy8.jpg -------------------------------------------------------------------------------- /2019/04/benchmarking-istio-and-linkerd-cpu/1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/benchmarking-istio-and-linkerd-cpu/1.png -------------------------------------------------------------------------------- /2019/04/benchmarking-istio-and-linkerd-cpu/2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/benchmarking-istio-and-linkerd-cpu/2.png -------------------------------------------------------------------------------- /2019/04/benchmarking-istio-and-linkerd-cpu/3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/benchmarking-istio-and-linkerd-cpu/3.png -------------------------------------------------------------------------------- /2019/04/benchmarking-istio-and-linkerd-cpu/4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/benchmarking-istio-and-linkerd-cpu/4.png -------------------------------------------------------------------------------- /2019/04/benchmarking-istio-and-linkerd-cpu/5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/benchmarking-istio-and-linkerd-cpu/5.png -------------------------------------------------------------------------------- /2019/04/benchmarking-istio-and-linkerd-cpu/6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/benchmarking-istio-and-linkerd-cpu/6.png -------------------------------------------------------------------------------- /2019/04/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative-1.png -------------------------------------------------------------------------------- /2019/04/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative-2.png -------------------------------------------------------------------------------- /2019/04/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative-3.png -------------------------------------------------------------------------------- /2019/04/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative-4.png -------------------------------------------------------------------------------- /2019/04/the-service-mesh-era-istios-role-in-the-future-of-hybrid-cloud/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | author: "Megan O'Keefe" 3 | translator: "osswangxining" 4 | original: "https://cloud.google.com/blog/topics/hybrid-cloud/the-service-mesh-era-istios-role-in-the-future-of-hybrid-cloud" 5 | reviewer: ["haiker2011"] 6 | title: "服务网格时代：Istio在混合云未来扮演的角色" 7 | description: "谈谈如何使用Istio将混合服务网格变为现实，以及Istio在混合云未来扮演的角色。" 8 | categories: "translation" 9 | tags: ["Hybrid", "Multicluster", "Istio", "Service Mesh"] 10 | originalPublishDate: 2019-04-02 11 | publishDate: 2019-04-08 12 | --- 13 | 14 | # 服务网格时代：Istio在混合云未来扮演的角色 15 | 16 | 欢迎回到我们关于Service Mesh和Istio的博客文章系列。 17 | 18 | 在之前的帖子中，我们讨论了Istio服务网格是什么，以及它为什么如此重要。然后，我们介绍了如何将Istio投入生产环境中，包括了如何进行高级应用程序部署和安全功能，到SRE监控最佳实践。 19 | 20 | 今天，在Google Cloud NEXT '19之前，我们正在谈论在各种环境中使用Istio，以及Istio如何帮助您释放混合云的强大功能。 21 | 22 | ## 为什么采用混合云？ 23 | 24 | 混合云可以采用多种形式。通常，混合云指的是跨公共云和私有（内部部署）云运行，而多云意味着跨多个公共云平台运行。 25 | 26 | 采用混合云或多云架构可以为您的组织带来诸多好处。例如，使用多个云提供商可以帮助您避免供应商锁定，并使得您为实现目标可选择最佳的云服务。使用云和本地环境，您可以同时享受云的优势（灵活性、可扩展性、成本降低）和本地的好处（安全性、低延迟、硬件复用）。如果您是首次迁移到云端，采用混合云步骤可以让您按照自己的节奏，以最适合您业务的方式进行。 27 | 28 | 根据我们在Google的经验以及我们从客户那里得到的信息，我们认为采用混合服务网络是简化云和本地环境中应用程序管理、安全性和可靠性的关键 - 无论您的应用程序是否在容器中运行，或是在虚拟机中运行。让我们来谈谈如何使用Istio将混合服务网格变为现实。 29 | 30 | ## 混合Istio：跨环境的网格 31 | 32 | Istio的一个关键特性是它为您的工作负载（例如Pod、Job、基于VM的应用程序）提供服务抽象。当您转向混合拓扑时，这种服务抽象变得更加重要，因为现在您不是只需要关注一个环境，而是需要关注若干个环境。 33 | 34 | 当您在一个Kubernetes集群上使用Istio时，您可以获得包括可见性、​​细粒度流量策略、统一遥测和安全性在内的微服务的所有管理优势。但是当您在多个环境中使用Istio时，您实际上是在为您的应用程序提供了一个新的超级能力。因为Istio不仅仅是Kubernetes的服务抽象，Istio也是一种在整个环境中标准化网络的方法。它是一种集中API管理并将JWT验证与代码分离的方法。它是跨云提供商的安全、零信任网络的快速通道。 35 | 36 | 那么所有这些魔法是如何发生的呢？混合Istio是指一组Istio Sidecar 代理，每一个Envoy代理位于所有服务的旁边，而这些服务可能运行在您的不同环境中的每一个虚拟机、每一个容器中，而且这些Sidecar代理之前互相知道如何跨边界交互。这些Envoy Sidecar代理可能由一个中央Istio控制平面管理，或由每个环境中运行的多个控制平面管理。 37 | 38 | 我们来看一些例子吧。 39 | 40 | ## 多集群Istio，一个控制平面 41 | 42 | 启用混合Istio的一种方法是配置一个远程Kubernetes集群，该集群连接到一个集中运行的Istio控制平面。如果在同一GCP项目中有多个GKE集群，则此设置很有用，注意的是两个集群中的Kubernetes pod需要相互通信。这种方式常用于以下场景：通过测试集群您可以使用新的功能并使其过渡到生产集群；准备好处理故障转移的备用集群，或跨地域或可用区的冗余集群。 43 | 44 | 该演示是在同一个GCP项目中的两个GKE集群，但是跨越了两个不同的可用区（us-central和us-east）。我们在一个集群上安装Istio 控制平面，在另一个集群上安装Istio的远程组件（包括sidecar代理注入器）。在这两个集群中，我们可以部署跨Kubernetes集群的示例应用程序。 45 | 46 | ![](http://ww1.sinaimg.cn/large/740de70aly1g1ufab9cslj212w0kjn0n.jpg) 47 | 48 | 关于这种单一控制平面方法的令人兴奋的事情是，我们不必改变任何有关我们的微服务如何相互通信的信息。例如，前端仍然可以使用本地Kubernetes DNS名称（cartservice:port）调用CartService 。此DNS解析有效，因为同一GCP项目中的GKE pod属于同一虚拟网络，因此允许跨群集进行直接的pod-to-pod通信。 49 | 50 | ## 多集群Istio，两个控制平面 51 | 52 | 现在我们已经看到了一个基本的多集群Istio示例，让我们更进一步演示另一种拓扑。 53 | 54 | 假设您在本地和云中或跨云平台运行应用程序。为了使Istio跨越这些不同的环境，两个集群内的pod必须能够跨越网络边界。 55 | 56 | 该演示使用两个Istio控制平面 - 每个集群一个 - 形成一个双头逻辑服务网格。两个集群间的流量交互是通过Istio的Ingress网关，而不是使用Sidecar代理直接相互通信。Istio Gateway也是一个Envoy代理，但它专门用于进出集群Istio网格的流量。 57 | 58 | ![](http://ww1.sinaimg.cn/large/740de70aly1g1uf9x9drej20xc0fediq.jpg) 59 | 60 | 为使此设置跨网络分区工作，每个Istio控制平面都有一个特殊的域名服务器（DNS）配置。在此双控制平面拓扑中，Istio安装辅助DNS服务器（CoreDNS），该服务器解析本地集群的外部服务的域名。对于那些外部服务，流量在Istio Ingress网关之间透传，然后转移到相关服务。 61 | 62 | 在此拓扑的演示中，我们将展示安装的工作原理，然后介绍如何配置跨两个集群运行的微服务能够互相通信。我们通过Istio ServiceEntry资源完成此操作。例如，我们将前端（集群2）的服务条目部署到集群1中。这样，集群1就知道集群2中运行的服务。 63 | 64 | 与第一个演示不同，这种双控制平面Istio设置不需要集群之间的扁平网络。这意味着您的集群之间pod可以有重叠的CIDR。此设置所需要的只是Istio网关暴露在Internet上。通过这种方式，每个集群内的服务可以在各自的环境中保持安全。 65 | 66 | ## 将虚拟机添加到Istio网格 67 | 68 | 除了容器之外，许多组织也使用虚拟机（VM）作为补充或者替代来运行其应用程序。如果您正在使用虚拟机，您仍然可以享受Istio网格带来的好处。此演示向您展示如何在GKE上运行Istio时集成Google Compute Engine实例。我们像以前一样部署相同的应用程序 但这一次，一个服务（ProductCatalog）被部署在Kubernetes集群之外的外部虚拟机上运行。 69 | 70 | ![](http://ww1.sinaimg.cn/large/740de70aly1g1uf9946qjj212w0n4ae7.jpg) 71 | 72 | 该GCE 虚拟机运行一组最小的Istio组件，以便能够与中心的Istio控制平面通信。然后，我们将Istio ServiceEntry对象部署到GKE集群，该集群在逻辑上将外部ProductCatalog服务添加到网格中。 73 | 74 | 这个Istio配置模型很有用，因为现在，所有其他微服务都可以引用 ProductCatalog，就好像它是在Kubernetes集群内部运行一样。从这里，您甚至可以为ProductCatalog添加Istio策略和规则，就像它在Kubernetes中运行一样; 例如，您可以为虚拟机的所有入站流量启用双向TLS。 75 | 76 | 请注意，虽然此示例使用Google Cloud VM进行演示，但您可以在物理机上或使用本地虚拟机运行相同的示例。通过这种方式，您可以将Istio的现代云原生原则带到任何地方运行的虚拟机中。 77 | 78 | ## 建立混合型未来 79 | 80 | 我们希望这些混合Istio演示中的一个或多个能够与现在您的组织中运行应用程序的方式产生共鸣。但我们也明白采用像Istio这样的服务网格意味着要承担复杂性和安装开销，此外还涉及迁移到微服务和Kubernetes相关的任何复杂性。在这种情况下，采用混合服务网格甚至更复杂，因为您正在处理不同的环境，每个环境都有自己的技术规范。 81 | 82 | Google Cloud致力于通过一致、现代化的跨平台设置帮助您简化日常云操作。这就是我们在GKE上创建Istio的原因，它可以在Google Kubernetes Engine（GKE）上一键安装Istio。它是我们在云服务平台（CSP）上工作的推动力。CSP是一种产品，可以帮助您的组织迁移到（并跨越）云——按照您自己的步调、以最适合您的方式。CSP依赖于开放的云堆栈——Kubernetes和Istio——来强调可移植性。今年我们很高兴CSP成为现实。 83 | 84 | 感谢您加入我们迄今为止的服务网格系列。请继续关注4月份Google Cloud NEXT上的主题演讲和混合云专题。在NEXT之后，我们将继续关于Istio操作的一些高级帖子。 85 | -------------------------------------------------------------------------------- /2019/04/what-is-a-service-mesh/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: https://www.nginx.com/blog/what-is-a-service-mesh/ 3 | author: "Floyd Smith of NGINX, Inc. and Owen Garrett of NGINX, Inc" 4 | translator: "garboy" 5 | reviewer: ["haiker2011", "SataQiu"] 6 | title: "NGINX眼中的服务网格" 7 | description: "本文对服务网格做了一个入门介绍，是一个很好的入门参考" 8 | categories: "translation" 9 | tags: ["servicemesh"] 10 | originalPublishDate: 2018-04-03 11 | publishDate: 2019-4-28 12 | --- 13 | 14 | [编者按] 15 | 16 | > 原文的两位作者对服务网格做了一个简要介绍，并对相关关键术语也做了解释，是一篇很好、简短的服务网格入门参考文档 17 | 18 | 服务网格是一种可配置、低延迟的基础结构层，被设计用于处理大量基于网络，基于API接口的应用程序间调用。服务网格用于保证容器间那些转瞬即逝的互相调用是高速、可靠并且安全的。网格提供关键能力，包括服务发现，负载均衡，加密，可观察，可追踪，具备认证与授权，并且支持断路器模式。 19 | 20 | 服务网格通常会为每一个服务实例提供一个代理实例(proxy instance)，一般叫做边车(sidecar)。边车用于处理服务间通信，监控以及安全相关问题--事实上，任何可以从服务实例抽象出来的东西，都可以放到边车里面。通过这种方式，开发者可以专注于处理开发、支持以及维护应用程序代码；运维团队可以维护服务网格以保证应用程序可用。 21 | 22 | Istio，发源于Google, IBM和Lyft，是当前最为知名的服务网格架构。Kubernetes，最早由Google设计，是现在唯一一个被Istio支持的容器调度框架（framework）。供应商不断再尝试寻找商业支持的Istio。我们很期待他们能够给开源社区带来价值。 23 | 24 | Istio并不是唯一的选择，还有一些其它的服务网格实现正在开发中。边车代理模式是目前最流行的，并且在Buoyant, HashiCorp, Solo.io及其它厂商的项目中使用。我们也有其它备选方案：Netflix的技术包也是其中的一种，在他们的方案中，服务网格主要通过应用程序包的方式被提供出来（Ribbon, Hysterix, Eureka, Archaius）。Azure的Service Fabric平台，通过在应用程序框架中内嵌服务网格类的能力，来达到同样的效果。 25 | 26 | 服务网格包含了一些约定俗成的术语： 27 | 28 | - **容器编排框架.** 随着越来越多的容器加入到应用程序基础架构中，一个独立的，用于监控和管理这些容器的工具-*容器编排框架*-就变为必需品。Kubernetes应运而生，当然也有其他竞争者，Docker Storm和Mesosphere DC/OS，这些产品也提供与Kubernetes的集成。 29 | - **服务与实例.（Kubernetes pods）** 实例是一个运行状态的微服务的副本。有时候实例也指一个单独的容器；在Kubernetes里面，一个实例是由一小组相互独立的容器（称作pod）组成。客户端通常访问*服务*而不是具体的实例或pod，因为服务是由一系列实例或pod组成，提供了扩展和容错功能。 30 | - **边车代理.** *边车代理*并行运行在一个单独实例或pod旁边。它的目的是为了路由，或称代理，也就是解决它并行的容器的对内/对外访问。该实例的边车与其他边车代理沟通，并且受容器编排框架的调度。很多服务网格通过这种边车代理模式来管理实例或pod的入站(*ingress*)和出站(*egress*)访问。 31 | - **服务发现.** 当一个实例需要和其它服务交互时，它需要能够找到-发现-其它服务的一个健康，可用的实例。通常是通过一次DNS查询来达到这个目标。容器编排框架会维护一个实例列表，用于接收这些请求并为DNS查询提供接口。 32 | - **加密.** 服务网格可以对请求和响应内容进行加密与解密操作，从而减轻各个服务的负担。同样网格也可以通过重用已有的、持续的连接，降低创建新连接的昂贵成本，从而来提高性能。最常见的加密方式是双向TLS(mTLS)，公钥基础设施（PKI）生成证书和密钥，以供边车代理使用。 33 | - **认证和授权.** 服务网格可以同时在应用程序外或者内进行认证与授权逻辑，确保发送到实例的请求都是合法的。 34 | - **断路器模式支持.** 服务网格可以支持[断路器模式](https://www.nginx.com/blog/microservices-reference-architecture-nginx-circuit-breaker-pattern)，这种方式可以切断不健康的实例，并在它们恢复健康后，重新回到服务实例池内。 35 | 36 | 服务网格中管理实例间网络流量的部分被称作*数据平面*。控制数据平面的那些配置信息，是由另一个*控制平面*来产生并部署的。控制平面通常包括，或者说被设计用于连接至API，命令行，并且提供一个图形化界面用于管理。 37 | 38 | ![img](./service-mesh-generic-topology.png) 39 | 40 | 控制平面用于数据平面中sidecar的配置项的分发 41 | 42 | 服务网格这种架构是用于解决使用容器和[微服务](https://www.nginx.com/blog/introduction-to-microservices/)后，对运维越来越高的要求。微服务领域的先行者包括Lyft, Netflix, Twitter，每一个都为每小时进进出出达到全球百万计的用户提供健壮的服务。（可以参考另一篇更加深入的文章[architectural challenges facing Netflix](https://www.nginx.com/blog/microservices-at-netflix-architectural-best-practices/).）对于那些没这么复杂的应用程序需求，一个简单的架构就足够了。 43 | 44 | 服务网格架构并不是解决所有应用程序运维和部署问题的灵丹妙药。架构师和开发者们有很多很好的工具，只有一种工具是榔头，同时，各种各样的问题中，也只有一类问题是钉子。NGINX的[微服务架构参考](https://www.nginx.com/blog/introducing-the-nginx-microservices-reference-architecture/)，包含了一系列不同的模型，并给出了一系列通过微服务的方法解决各种不同问题的方法。 45 | 46 | 这些元素共同构成了服务网格架构--包含NGINX，容器，Kubernetes，与微服务架构方法--可以被用在，同时也被高效的用在非服务网格实现方法上。比如，Istio最早被当作完整的服务网格架构来开发，但是它的模块化使得开发者可以随时只选取他们需要的部分来使用。顺着这种思路，哪怕你并不确定是否需要，什么时候需要实现完整的服务网格应用，了解服务网格的概念也是非常有必要的。 47 | -------------------------------------------------------------------------------- /2019/04/what-is-a-service-mesh/service-mesh-generic-topology.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/04/what-is-a-service-mesh/service-mesh-generic-topology.png -------------------------------------------------------------------------------- /2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g262ptg24tj30i20c1t9p.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g262ptg24tj30i20c1t9p.jpg -------------------------------------------------------------------------------- /2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g2uc247iboj315o0tndmy.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g2uc247iboj315o0tndmy.jpg -------------------------------------------------------------------------------- /2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g2ucct7lxoj315o0tnn58.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g2ucct7lxoj315o0tnn58.jpg -------------------------------------------------------------------------------- /2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g2ucjbe9lbj315o0tn10u.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g2ucjbe9lbj315o0tn10u.jpg -------------------------------------------------------------------------------- /2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g2uclnkuu6j315o0tnahx.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g2uclnkuu6j315o0tnahx.jpg -------------------------------------------------------------------------------- /2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g2ucs0jxkxj315o0tnjzb.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g2ucs0jxkxj315o0tnjzb.jpg -------------------------------------------------------------------------------- /2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g2ucwd5qmaj315o0tnjz5.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g2ucwd5qmaj315o0tnjz5.jpg -------------------------------------------------------------------------------- /2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g2ud0nxutaj315o0tnwln.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/canary-release-strategy-using-kubernetes-istio-and-helm/0071hauBly1g2ud0nxutaj315o0tnwln.jpg -------------------------------------------------------------------------------- /2019/05/deploying-envoy-proxy/envoy-blog-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/deploying-envoy-proxy/envoy-blog-1.png -------------------------------------------------------------------------------- /2019/05/deploying-envoy-proxy/envoy-blog-2.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/deploying-envoy-proxy/envoy-blog-2.png -------------------------------------------------------------------------------- /2019/05/deploying-envoy-proxy/envoy-blog-3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/deploying-envoy-proxy/envoy-blog-3.png -------------------------------------------------------------------------------- /2019/05/deploying-envoy-proxy/envoy-blog-4.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/deploying-envoy-proxy/envoy-blog-4.png -------------------------------------------------------------------------------- /2019/05/deploying-envoy-proxy/envoy-blog-5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/deploying-envoy-proxy/envoy-blog-5.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/1.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/10.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/11.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/11.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/12.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/12.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/13.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/13.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/14.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/14.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/15.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/15.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/16.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/16.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/17.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/17.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/18.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/18.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/19.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/19.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/2-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/2-1.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/20.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/20.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/21.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/21.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/3.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/3.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/4-1.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/4-1.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/5.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/5.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/6.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/6.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/7.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/7.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/8.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/8.png -------------------------------------------------------------------------------- /2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/9.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/9.png -------------------------------------------------------------------------------- /2019/05/kubernetes-service-mesh/empty-dashboard.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/kubernetes-service-mesh/empty-dashboard.png -------------------------------------------------------------------------------- /2019/05/kubernetes-service-mesh/index.md: -------------------------------------------------------------------------------- 1 | --- 2 | original: "https://akomljen.com/kubernetes-service-mesh/" 3 | author: "ALEN KOMLJEN" 4 | translator: "chengwhynot" 5 | reviewer: ["haiker2011","loverto"] 6 | title: "Kubernetes Service Mesh" 7 | summary: "文章介绍了为什么要用服务网格，以及简单的介绍了两个重要实现：Istio和Linkerd，鼓励大家上手实验。" 8 | categories: "translation" 9 | tags: ["service mesh","Istio","Linkerd"] 10 | originalPublishDate: 2018-01-28 11 | publishDate: 2019-05-16 12 | --- 13 | 14 | ## 基于Kubernetes的服务网格 15 | 16 | [编者按] 17 | 18 | > 文章介绍了基于Kubernetes的服务网格，简要的说明了服务网格的作用，sidecar的作用以及服务网格两个重要实现：Istio与Linkerd的起源和结构，鼓励大家上手尝试。 19 | 20 | [ALEN KOMLJEN](https://akomljen.com/author/alen/) 2018年1月28日，阅读时间4分钟 21 | 22 | 几个月前我同事问起我对于如何集成[Linkerd](https://linkerd.io/)到我们新的运行在[Kubernetes](https://akomljen.com/tag/kubernetes/)应用里面有什么想法。我的第一反应是，嘿，难道Kubernetes服务和[ingress](https://akomljen.com/tag/ingress/)还不够么？你能够基于它们做很多事情了。再考虑服务网格的话似乎有点过度设计。通常你有一些API只对内部网络开放，然而对于现在流行的应用来说，这并不够。API通常暴露在互联网上并且也有非常大的流量。你需要在流量上有更多的控制。甚至你还需要做API版本化，做金丝雀部署，观察并记录每一个请求。这就引入了服务网格。无论你用[Linkerd](https://linkerd.io/)或是[Istio](https://istio.io/)，原理上都是一样的。 23 | 24 | ### 为什么要用服务网格？ 25 | 26 | 服务网格并不是和Kubernetes一起出现。然而，因为有Kubernetes，服务网格更容易被引入到你的环境中。有两个逻辑组件组成了服务网格。我们已经有了pod用于承载各个容器。Sidecar是另一个绝好的例子用于扩展和加强pod里面的主要容器。在服务网格语境里，sidecar是服务代理或者数据平面。 27 | 28 | > 服务网格是云原生的核心组件 29 | 30 | 为了更好的理解服务网格，你需要理解代理和反向代理这两个术语。**代理**，用一句话说，用于接收流量并中转到其它地方。**反向代理**，从各个地方接收流量并转交给各个服务。这种情况下，所有的客户只和一个代理实例交流。把数据平面想象为一个反向代理。Ingress也是Kubernetes里面用于暴露服务的反向代理。Ingress可以中止SSL，提供基于名称的路由，并且它主要就干这个事情。对于Kubernetes服务也是一样。如果你需要更复杂的路由该怎么做呢？ 31 | 32 | 下面列举一些其它服务网格可以做的事情： 33 | 34 | - 负载均衡 35 | - 精细流量策略 36 | - 服务发现 37 | - 服务监控 38 | - 追踪 39 | - 路由 40 | - 服务与服务的安全通信 41 | 42 | 不仅有sidecar代理，所有的服务网格解决方案还包含控制器，用于定义sidecar容器应该如何工作。服务网格的控制平面是一个集中的、管理所有的服务网格和服务代理的地方。这个控制面板记录网络信息，所以它也是一个网络监控工具。 43 | 44 | 所以，为什么要用服务网格？答案很简单，你可以做上面的任何事情并且不需要修改代码。它能够节省时间与金钱。不仅如此，更重要的是，你不能跳过测试，因为它对于初学者太复杂。甚至你可以通过[Istio故障注入](https://istio.io/docs/concepts/traffic-management/#fault-injection)模拟不同的场景，来测试系统对于失败的反应。 45 | 46 | ### Linkerd2与Istio 47 | 48 | 在一开始，我提到过两个在Kubernetes上创建服务网格的著名的解决方案。未来也许还会有其它更多的解决方案。每一个产品都试图用自己的方式解决问题，相互之间肯定会有重复的地方。 49 | 50 | [Buoyant](https://buoyant.io/)，这家公司创造了Linkerd，同时还创造了Conduit服务。近期，Conduit被合并到Linkerd项目，称作**Linkerd2**。buoyant团队把Linkerd服务网格变成了一个更加通用的解决方案。它用Java编写，这意味着它很重。每一个pod会有一个或更多的容器，一个sidecar。[Linkerd2](https://linkerd.io/2/overview/)设计应用于Kubernetes。它的开发语言包含Go-控制平面，和Rust-一个原生的服务代理，超级轻量、快速并安全。你可以定义重试和超时，定义编排规则，以及加密（TLS），同时还支持根据策略通过或拒绝请求。不仅如此，它还有一个很漂亮的控制台： 51 | 52 | ![linkerd2_dashboard](./empty-dashboard.png) 53 | 54 | 如果你喜欢控制台的话也可以用`linkerd`CLI。 55 | 56 | Linkerd的[入门向导](https://linkerd.io/2/getting-started/)非常不错，你可以试一试。如果想学习更多，可以看看它的[官方文档](https://linkerd.io/docs/)。 57 | 58 | **Istio**当前支持Kubernetes和[Nomad](https://www.nomadproject.io/)，将来会添加更多的功能。Istio是一个多平台解决方案。它可以做微服务流量管理，策略应用以及聚合采样信息。Istio也是Go语言编写的轻量应用，但不同于Linkerd2，它使用[Envoy](https://www.envoyproxy.io/)来做服务代理。下图说明Istio中各个部分是如何组合工作的: 59 | 60 | ![istio_architecture](./arch.svg) 61 | 62 | 我喜欢Istio的其中一点是[sidecar自动注入](https://istio.io/docs/setup/kubernetes/sidecar-injection.html#automatic-sidecar-injection)，前提是你已经使用[Helm](https://akomljen.com/package-kubernetes-applications-with-helm/)来发布应用，这样的话就不需要手工把sidecar注入到kubernetes的配置文件里面。 63 | 64 | 在Kubernetes上安装Istio请参考[这篇快速指南](https://istio.io/docs/setup/kubernetes/quick-start.html)。其它关于Istio的信息，请参考它的[官方文档](https://istio.io/docs/)。 65 | 66 | 这两个产品都是开源的。无论哪一个服务网格方式适合你，它们两个都很容易上手实验。不超过5分钟就可以把它跑起来。我鼓励你都去试一试然后再做决定。目前阶段Istio实现的功能比Linkerd2多了很多，并且也是一个稳定版本。 67 | 68 | ### 总结 69 | 70 | 我希望这篇文章很好的介绍了服务网格。这篇文章并不是Linkerd2和Istio之间的比较。我列举了一些功能点，这样你可以了解一下服务网格给Kubernetes带来了什么。请继续关注我们的后续文章。 71 | -------------------------------------------------------------------------------- /2019/05/preventing-systemic-failure-circuit-breaking-part-2/cover.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/preventing-systemic-failure-circuit-breaking-part-2/cover.jpg -------------------------------------------------------------------------------- /2019/05/preventing-systemic-failure-circuit-breaking-part-2/hystrix.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/preventing-systemic-failure-circuit-breaking-part-2/hystrix.png -------------------------------------------------------------------------------- /2019/05/preventing-systemic-failure-circuit-breaking-part-2/monitor-control.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/preventing-systemic-failure-circuit-breaking-part-2/monitor-control.png -------------------------------------------------------------------------------- /2019/05/preventing-systemic-failure-circuit-breaking-part-2/refine.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/servicemesher/weekly/13d9dcc667a4096e43938d651f055d116a9d8e8b/2019/05/preventing-systemic-failure-circuit-breaking-part-2/refine.png -------------------------------------------------------------------------------- /ISSUE_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | ## 类型 2 | 3 | 本文的类型为： 4 | 5 | 原创 6 | 7 | 翻译 8 | 9 | 转载 10 | 11 | ## 文章信息 12 | 13 | - 原文链接： 14 | 15 | - 原文发布时间： 16 | 17 | - 作者： 18 | 19 | - 标签： 20 | 21 | ## 当前进度 22 | 23 | - [ ] 已提交文章线索 24 | - [ ] 已有人认领翻译或为原创文章 25 | - [ ] 已提交 PR 26 | - [ ] 正在review 27 | - [ ] review 完成等待发布 28 | - [ ] 已发布到 http://www.servicemesher.com 29 | - [ ] 已发布到 ServiceMesher 微信公众号 -------------------------------------------------------------------------------- /OWNERS: -------------------------------------------------------------------------------- 1 | approvers: 2 | - haiker2011 3 | - loverto 4 | - malphi 5 | - rootsongjc 6 | - SataQiu 7 | - shaobai 8 | - x19990416 9 | -------------------------------------------------------------------------------- /PULL_REQUEST_TEMPLATE.md: -------------------------------------------------------------------------------- 1 | 请审校者在合并该 PR 前需要检查以下内容： 2 | 3 | - [ ] Header 设置正确，包括文章的类型、tag、分类、作者、译者、摘要、reviewer 发布时间等信息 4 | - [ ] 关联 Issue 编号 https://github.com/servicemesher/trans/issues/${ISSUE_ID} 5 | - [ ] 该 PR Assigned 给了提交者 6 | - [ ] 指定了 Reviewer 7 | - [ ] 为 PR 明确了 label 信息，如 categories、kind、size、tag、status 8 | - [ ] 所有代码片段都指定了代码语言 9 | - [ ] 翻译的文章添加了**编者按** 10 | - [ ] 文章遵守了路径规范 `YEAR/MONTH/TITLE/index.md`，例如 `2019/04/new-blog/index.md` 11 | - [ ] 图片保存了在 GitHub上，跟文章在同级目录 12 | - [ ] 文章标题简短且语义明确 13 | - [ ] 文章语句通顺，没有语病和格式问题 14 | - [ ] 文中没有不可达的链接 15 | - [ ] 提交者同意授权 ServiceMesher 公众号和 http://www.servicemesher.com 发布我原创或翻译的文章 16 | 17 | 当所有以上问题都确定之后，可以由管理者合并 PR 并关闭关联 issue。 18 | 19 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # ServiceMesher Weekly 2 | 3 | 本仓库用于存储 ServiceMesher 社区周报。 4 | 5 | ![ServiceMesher](https://ws1.sinaimg.cn/large/006tKfTcly1g0cz6429t2j31jt0beq9s.jpg) 6 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180523-20180529.md: -------------------------------------------------------------------------------- 1 | # Service Mesh weekly #1 2018.05.23-2018.05.29 2 | 3 | ## 博客 4 | 5 | 1. Envoy 最新版的官方文档翻译工作完成，这是社区的第一个共同参与的活动，共 27 人参加，详见 http://www.servicemesher.com/envoy/ 6 | 2. Service Mesh 资讯情报整理工作展开，所有资料归档在 ，欢迎大家踊跃提交 7 | 3. 万众期待的 Istio 0.8 LTS 发布了！详见 http://www.servicemesher.com/blog/istio-0.8-release-note/ 8 | 4. Istio 的 GitOps——像代码一样管理 Istio 配置，详见 http://www.servicemesher.com/blog/gitops-for-istio-manage-istio-config-like-code/ 9 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180604-20180610.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #2 2018.06.04 - 2018.06.10 2 | 3 | ## 活动 4 | 5 | 1. Service Mesh爱好者社区第一次线下meetup（6月30日星期六，杭州）预告及讲师/topic征集，见 https://mp.weixin.qq.com/s/n4qi4EkYoGKMARySizwBSQ 6 | 7 | ## 博客 8 | 9 | 1. 使用 MINIKUBE-IN-A-CONTAINER 和 JENKINS 构建 ISTIO，http://www.servicemesher.com/blog/building-istio-with-minikube-in-a-container-and-jenkins/ 10 | 2. Istio 0.8 种的 helm chart 解析 ，http://www.servicemesher.com/blog/helm-chart-for-istio-0.8/ 11 | 3. 使用 Istio 为微服务提供高级流量管理和请求跟踪功能，http://www.servicemesher.com/blog/manage-microservices-traffic-using-istio/ 12 | 4. Istio v1aplha3 routing API介绍，http://www.servicemesher.com/blog/introducing-the-istio-v1alpha3-routing-api/ 13 | 14 | ## 新闻 15 | 16 | 1. Conduit v0.4.2 发布，这是向生产可用版本的一步重要跨越，https://github.com/runconduit/conduit/releases -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180611-20180617.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #3 2018.06.11 - 2018.06.17 2 | 3 | ## 博客 4 | 5 | 1. 在Istio中追踪grpc - https://servicemesher.github.io/blog/tracing-grpc-with-istio/ 6 | 2. AspenMesh的Service Mesh之路 - https://servicemesher.github.io/blog/the-path-to-service-mesh/ 7 | 3. Twistlock使Istio的安全层更强大，更易于监控 - https://servicemesher.github.io/blog/twistlock-makes-istios-security-layer-more-robust-easier-to-monitor/ 8 | 4. Istio服务网格的崛起 - https://servicemesher.github.io/blog/the-rise-of-the-istio-service-mesh/ 9 | 10 | ## 活动 11 | 12 | 1. Service Mesh线下meetup第一期杭州站，6月30日（星期六），蚂蚁Z空间，只剩25个名额，报名从速 13 | 2. Istio官网文档中文版开始接受PR，现可预览中文页面 https://preliminary.istio.io/zh 欢迎大家参与 14 | 15 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180625-20180701.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #4 2018.06.25 - 2018.07.01 2 | 3 | ## 博客 4 | 5 | 1. 一家日本的食谱网站分享了Service Mesh的真实案例：服务网格在Cookpad网站中的实践，http://www.servicemesher.com/blog/service-mesh-in-cookpad/ 6 | 2. Matt Klein讲述Envoy API设计的历史：Service Mesh中的通用数据平面API设计，http://www.servicemesher.com/blog/the-universal-data-plane-api/ 7 | 3. 容器、服务网格和 API 网关：从边缘开始，http://www.servicemesher.com/blog/containers-service-mesh-and-api-gateways-it-starts-at-the-edge/ 8 | 4. Aspen Mesh（隶属于F5）的Andrew Jenkins回答关于使用Service Mesh来充分利用微服务的8个问题：http://www.servicemesher.com/blog/making-most-out-microservices-service-mesh/ 9 | 5. 实战教程：利用Let's Encrypt 为Istio（Envoy）添加TLS 支持 http://www.servicemesher.com/blog/istio-envoy-cert-manager-lets-encrypt-for-tls/ 10 | 11 | ## 活动 12 | 13 | 1. Service Mesh meetup杭州站圆满落幕，下一站北京，请关注我们的微信公众号和官方网站获取meetup的PPT和活动预告 14 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180702-20180708.md: -------------------------------------------------------------------------------- 1 | # Service Mesh weekly #5 2018.07.02 - 2018.07.08 2 | 3 | ## 博客 4 | 5 | 1. 业界大咖采访录，InfoQ访谈：使用服务网格的微服务通信与治理 - http://www.servicemesher.com/blog/vp-microservices-communication-governance-using-service-mesh/ 6 | 2. Service Mesh增加新玩家，Consul 1.2发布 - http://www.servicemesher.com/blog/consul-1-2-service-mesh/ 7 | 3. 使用Kubernetes和Istio对基于容器基础设施的全面服务监控 - http://www.servicemesher.com/blog/comprehensive-container-based-service-monitoring-with-kubernetes-and-istio/ 8 | 4. Conduit已出局，Conduit 0.5 发布 —— 以及 R.I.P. Conduit - https://blog.fleeto.us/post/rip-conduit/ 9 | 5. 使用Istio控制Serverless架构Fn Project中的函数间流量路由 - http://www.servicemesher.com/blog/traffic-routing-between-fn-functions-using-fn-project-and-istio-fd/ 10 | 11 | ## 活动 12 | 13 | 1. Service Mesh历届meetup资料仓库 - https://github.com/servicemesher/meetup-slides -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180709-20180715.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #6 2018.07.09 - 2018.07.15 2 | 3 | ## 博客 4 | 5 | 本周给大家带来的两个系列文章。 6 | 7 | **速率限制系列文章** 8 | 9 | - 速率限制part1—分布式系统的一个实用工具：http://www.servicemesher.com/blog/rate-limiting-a-useful-tool-with-distributed-systems-part1/ 10 | - 速率限制part2—作用于API网关的速率限制：http://www.servicemesher.com/blog/rate-limiting-for-api-gateway-daniel-bryant-part2/ 11 | - 速率限制part3—基于Ambassador API网关实现Java速率限制服务：http://www.servicemesher.com/blog/implementing-a-java-rate-limiting-service-for-the-ambassador-api-gateway-part3/ 12 | - 速率限制系列part4—为Ambassador API网关设计速率限制服务：http://www.servicemesher.com/blog/designing-a-rate-limiting-service-for-ambassador-part-4/ 13 | 14 | **Istio源码解析系列** 15 | 16 | - Istio源码解析系列part1—Istio源码架构介绍及开发环境搭建：http://www.servicemesher.com/blog/istio-deepin-part1-framework-and-environment/ 17 | - Istio源码解析系列part2—服务治理配置生效流程解析：http://www.servicemesher.com/blog/istio-deepin-part2-serivce-management-workflow/ 18 | - Istio源码解析系列part3—Mixer工作流程浅析 -http://www.servicemesher.com/blog/istio-deepin-part3-mixer-workflow/ 19 | 20 | --- 21 | 22 | 本文归档到 https://github.com/servicemesher/trans ，打造Service Mesh领域最全的中文资料库。 -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180716-20180722.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #7 2018.07.16 - 2018.07.22 2 | 3 | ## 博客 4 | 5 | - 蚂蚁金服开源SOFAMesh和Go语言版的数据平面SOFA MOSN：http://www.servicemesher.com/blog/introducing-sofamesh-a-solution-for-large-scale-service-mesh-by-ant-financial/ 6 | - 使用Istio分布式跟踪应用程序：http://www.servicemesher.com/blog/distributed-tracing-istio-and-your-applications/ 7 | - 使用Istio 0.8对Kubernetes进行A/B测试：http://www.servicemesher.com/blog/ab-testing-on-kubernetes-with-istio-0.8/ 8 | 9 | ## 活动 10 | 11 | - Service Mesh Meetup北京站活动报名：http://www.servicemesher.com/activity/ 名额已满，无法现场参加的可以通过IT大咖说观看直播。 12 | 13 | --- 14 | 15 | 本文归档到 https://github.com/servicemesher/trans ，打造Service Mesh领域最全的中文资料库。 -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180723-20180729.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #8 2018.07.23 - 2018.07.29 2 | 3 | ## 博客 4 | 5 | - Service Mesh数据平面SOFAMosn深层揭秘 - http://www.servicemesher.com/blog/sofa-mosn-deep-dive/ 6 | - Istio 1.0发布，已生产就绪! - http://www.servicemesher.com/blog/announcing-istio-1.0/ 7 | - Service Mesh如何解决微服务中的3个主要挑战 - http://www.servicemesher.com/blog/how-service-mesh-addresses-3-major-microservices/ 8 | - 服务网格架构激活了容器网络管理—来自于服务网格创建者们的见解与展望 - http://www.servicemesher.com/blog/service-mesh-architecture-radicalizes-container-networking/ 9 | - Service Mesh架构解析 - http://www.servicemesher.com/blog/service-mesh-architectures/ 10 | 11 | ## 活动 12 | 13 | - 7月29日，第二届Service Mesh Meetup在北京举行，第二届Service Mesh Meetup北京站回顾 - http://www.servicemesher.com/blog/beijing-meetup-20180729/ 14 | 15 | --- 16 | 17 | 本文归档到 https://github.com/servicemesher/trans ，打造Service Mesh领域最全的中文资料库。 -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180730-20180805.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #9 2018.07.30 - 2018.08.05 2 | 3 | ## 博客 4 | 5 | - Istio 1.0发布，已生产就绪！- http://www.servicemesher.com/blog/announcing-istio-1.0/ 6 | - 微服务中的Sidecar设计模式解析 - http://www.servicemesher.com/blog/sidecar-design-pattern-in-microservices-ecosystem/ 7 | - 第二届Service Mesh Meetup北京站回顾 - http://www.servicemesher.com/blog/beijing-meetup-20180729/ 8 | 9 | ## 资料分享 10 | 11 | - 历届Service Mesh Meetup的幻灯片归总 - https://github.com/servicemesher/meetup-slides 12 | 13 | ## 社区活动 14 | 15 | - 社区新增Twitter账号 https://twitter.com/servicemesher 欢迎关注 16 | - 社区新增Slack https://servicemesher.slack.com 需要邀请才能加入，主要负责社区的活动组织与资料库建设 -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180806-20180812.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #10 2018.08.06 - 2018.08.12 2 | 3 | ## 博客 4 | 5 | - 服务网格加速金融科技向微服务转型 - http://www.servicemesher.com/blog/enabling-the-financial-services-shift-to-microservices/ 6 | - 基于Kubernetes和Istio的Serverless框架Knative解析之Autoscaler - http://www.servicemesher.com/blog/knative-serving-autoscaler-single-tenancy-deep-dive/ 7 | - Istio service mesh示例教程汇总 - http://www.servicemesher.com/blog/istio-tutorials-collection/ 8 | - 采纳运行在Kubernetes上的Istio服务网格的利弊分析 - http://www.servicemesher.com/blog/istio-service-mesh-tech-boosts-kubernetes-work-with-trade-offs/ -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180813-20180819.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #11 2018.08.06 - 2018.08.12 2 | 3 | ## 博客 4 | 5 | - 为什么你应该关心Istio gateway - http://www.servicemesher.com/blog/why-you-should-care-about-istio-gateways/ 6 | - 使用Cilium增强Istio—通过Socket感知BPF程序 - http://www.servicemesher.com/blog/how-cilium-enhances-istio-with-socket-aware-bpf-programs/ 7 | - Istio Service Mesh命令行工具Istioctl完全使用指南 - https://preliminary.istio.io/zh/help/ops/traffic-management/proxy-cmd/ 8 | - Istio 1.0 的实战测试 - https://mp.weixin.qq.com/s/-r9sPp7woEux7jluvkmT3w 9 | - 蚂蚁金服开源Go语言版Service Mesh数据平面SOFAMosn性能报告 - https://github.com/alipay/sofa-mosn/blob/master/docs/reference/PerformanceReport.md 10 | 11 | ## 活动预告 12 | 13 | - 2018年第三届Service Mesh Meetup深圳站报名 - 8月25日（周六）http://www.huodongxing.com/event/3453378014200 -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180820-20180826.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #12 2018.08.20 - 2018.08.26 2 | 3 | ## 博客 4 | 5 | - 应用程序安全性和正确性的责任不能推卸给Istio和任何服务网格 - http://www.servicemesher.com/blog/application-safety-and-correctness-cannot-be-offloaded-to-istio-or-any-service-mesh/ 6 | - 使用Let’s Encrypt在Kubernetes上保护Istio的Ingress服务 - http://www.servicemesher.com/blog/securing-ingress-services-in-istio-with-lets-encrypt-on-kubernetes/ 7 | - Google加持Istio—这可能比Kubernetes和Serverless产生更大影响力 - http://www.servicemesher.com/blog/google-istio-bigger-kubernetes-serverless/ 8 | - 企业级服务网格架构之路解读—Service Mesh在会话层解耦 - http://www.servicemesher.com/blog/the-enterprise-path-to-service-mesh-architectures/ 9 | 10 | ## 活动 11 | 12 | - 8月25日（周六）2018年第三届Service Mesh Meetup深圳站 - http://www.servicemesher.com/activity/ 13 | 14 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180827-20180902.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #13 2018.08.27 - 2018.09.02 2 | 3 | ## 博客 4 | 5 | - Cilium 1.2发布—DNS安全性策略、EKS支持、ClusterMesh、kube-router集成等 - http://www.servicemesher.com/blog/cilium1.2-dns-security-policies-eks-support-clustermesh-kube-router-integration/ 6 | - IBM云计算CTO讲述Istio项目的起源、分工及目标 - http://www.servicemesher.com/blog/istio-aims-to-be-the-mesh-plumbing-for-containerized-microservices/ 7 | - 教程|使用Istio实现一个Service Mesh以简化微服务间的通信模式 - http://www.servicemesher.com/blog/hands-on-canary-deployments-with-istio-and-kubernetes/ 8 | - 蚂蚁金服开源的 SOFAMesh 的通用协议扩展解析 - http://www.servicemesher.com/blog/ant-financial-sofamesh-common-protocol-extension/ 9 | - Istio Service Mesh中的授权与鉴权概念详解 - https://mp.weixin.qq.com/s/v0YAVNUcm6mQOwyBWZw5pw 10 | 11 | ## 活动 12 | 13 | - 8月25日（周六）2018年第三届Service Mesh Meetup深圳站回顾 - http://www.servicemesher.com/blog/service-mesh-meetup-shenzhen-20180825/ 14 | 15 | - Istio官网中文同步活动已接近尾声，将随Istio 1.1同时发布，了解如何参与请访问，欢迎大家更多的提交文章线索和原创文章请访问https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180903-20180909.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #14 2018.09.03 - 2018.09.09 2 | 3 | ## 博客 4 | 5 | - 在Play with Kubernetes平台上以测试驱动的方式部署Istio - http://www.servicemesher.com/blog/test-drive-your-first-istio-deployment-using-play-with-kubernetes-platform-cloud-computing/ 6 | - 后Kubernetes时代的微服务 - http://www.servicemesher.com/blog/microservices-post-kubernetes/ 7 | - Envoy服务网格在Lyft的实践及未来路线图 - http://www.servicemesher.com/blog/envoy-service-mesh-cascading-failure/ 8 | - 使用服务网格提高安全性：Christian Posta带你探索Istio的新功能 - https://mp.weixin.qq.com/s/2upM5Jo4JAiMy-ykBvWRlA 9 | 10 | ## 活动 11 | 12 | - Istio官网中文同步活动已接近尾声，将随Istio 1.1同时发布，了解如何参与请访问，欢迎大家更多的提交文章线索和原创文章请访问https://github.com/servicemesher/trans 13 | 14 | 本文归档到https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180910-20180916.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #15 2018.09.10 - 2018.09.16 2 | 3 | ## 博客 4 | 5 | - [教程|使用Istio在Kubernetes集群中实现金丝雀部署 by Kublr Team](http://www.servicemesher.com/blog/hands-on-canary-deployments-with-istio-and-kubernetes2/) 6 | - [服务网格的控制平面和边缘代理的重要性 by Daniel Bryant](http://www.servicemesher.com/blog/the-importance-of-control-planes-with-service-mesh/) 7 | - [Dubbo on x-protocol——SOFAMesh中的x-protocol示例演示 by 彭泽文](http://www.servicemesher.com/blog/dubbo-on-x-protocol-in-sofa-mesh/) 8 | - [理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫持 by 宋净超（Jimmy Song）](http://www.servicemesher.com/blog/envoy-sidecar-injection-in-istio-service-mesh-deep-dive/) 9 | 10 | ## 新闻 11 | 12 | - [F5公司Aspen Mesh 1.0发布，基于Istio 1.0](http://www.servicemesher.com/blog/aspen-mesh-released/) 13 | 14 | ## 活动 15 | 16 | - [蚂蚁金服开源的Go语言版ServiceMesh数据平面SOFAMosn开设 \源码分析共建小组](https://mp.weixin.qq.com/s/j7o6Ex4gZpuOHJNgWmjOtA) 17 | - Istio官网中文同步活动已接近尾声，将随Istio 1.1同时发布，了解如何参与请访问，提交文章线索和原创文章请访问https://github.com/servicemesher/trans 18 | 19 | 本文归档到https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180918-20180923.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #16 2018.09.18 - 2018.09.23 2 | 3 | ## 博客 4 | 5 | - [8款开源的Kubernetes Ingress Controller/API Gateway推荐](http://www.servicemesher.com/blog/nginx-ingress-vs-kong-vs-traefik-vs-haproxy-vs-voyager-vs-contour-vs-ambassador/) 6 | 7 | - [Kong 1.0发布，从网关转型为服务控制平台](http://www.servicemesher.com/blog/kong-at-1-0-a-service-control-platform/) 8 | 9 | - [Linkerd 2.0 GA版本发布](http://www.servicemesher.com/blog/linkerd-2-0-in-general-availability/) 10 | 11 | - [Service Mesh的未来将与Knative和Apahce Whisk等技术和谐共存——采访RedHat的Istio产品经理](http://www.servicemesher.com/blog/istio-service-mesh-interview-redbear-brian-harrington/) 12 | 13 | ## 活动 14 | 15 | - 云栖大会，9月18至21日在杭州召开，其间蚂蚁金服CodeLab中[使用SOFAMesh在蚂蚁金服Kubernetes服务上实现跨语言调用](https://mp.weixin.qq.com/s/OzcN2CWf7RFxHjmj3EYCCA)现场体验 16 | 17 | 本文归档到https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20180924-20181007.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #16 2018.09.24 - 2018.10.07 2 | 3 | 这期周报正好遇到了国庆假期。 4 | 5 | ## 博客 6 | 7 | - [Envoy 中的 xDS REST 和 gRPC 协议详解](http://www.servicemesher.com/blog/envoy-xds-protocol/) 8 | 9 | - [Istio和Kubernetes帮助Trulia房产网站消除单体架构增强微服务的可观测性](http://www.servicemesher.com/blog/microservice-observability-with-istio/) 10 | 11 | - [通过消除对特权容器的需求来提高Istio Deployment的安全性](http://www.servicemesher.com/blog/increasing-security-of-istio-deployments-by-removing-the-need-for-privileged-containers/) 12 | 13 | - [Red Hat OpenShift发布Istio预览版](http://www.servicemesher.com/blog/istio-on-openshift-technology-preview/) 14 | 15 | ## 活动 16 | 17 | - 无 18 | 19 | 本文归档到https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20181008-20181014.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #16 2018.10.08 - 2018.10.14 2 | 3 | ## 博客 4 | 5 | - [API管理和服务网格——为什么说服务网格无法替代API管理](http://www.servicemesher.com/blog/api-management-and-service-mesh/) 6 | 7 | - [SOFAMesh中的多协议通用解决方案x-protocol介绍系列（2）——快速解码转发](http://www.servicemesher.com/blog/x-protocol-rapid-decode-forward/) 8 | 9 | - [容器编排无法解决微服务的所有问题，你还需要服务网格](http://www.servicemesher.com/blog/going-beyond-container-orchestration/) 10 | 11 | - [SOFAMesh中的多协议通用解决方案x-protocol介绍系列（3）——TCP协议扩展](http://www.servicemesher.com/blog/x-protocol-tcp-protocol-extension/) 12 | 13 | ## 活动 14 | 15 | - 无 16 | 17 | 本文归档到https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20181015-20181021.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #17 2018.10.15 - 2018.10.21 2 | 3 | ## 博客 4 | 5 | - [Istio微服务平台集成实践](http://www.servicemesher.com/blog/istio-paas-integration/) 6 | 7 | - [教程|构建生产就绪的Istio Adapter](http://www.servicemesher.com/blog/set-sail-a-production-ready-istio-adapter/) 8 | 9 | - [使用Go语言操作Istio和其他Kubernetes CRD](http://www.servicemesher.com/blog/manipulating-istio-and-other-custom-kubernetes-resources-in-golang/) 10 | 11 | - [SOFAMesh中的多协议通用解决方案x-protocol介绍系列（3）——TCP协议扩展](http://www.servicemesher.com/blog/x-protocol-tcp-protocol-extension/) 12 | 13 | - [容器编排无法解决微服务的所有问题，你还需要服务网格](http://www.servicemesher.com/blog/going-beyond-container-orchestration/) 14 | 15 | ## 活动 16 | 17 | - 上海KubeCon ServiceMesher代表团成立 18 | 19 | 本文归档到https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20181022-20181028.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #18 2018.10.22- 2018.10.28 2 | 3 | ## 博客 4 | 5 | - [小米正式开源Istio管理面板Naftis](http://www.servicemesher.com/blog/naftis-istio-dashboard-xiaomi/) 6 | 7 | - [Istio1.1.0下的TCP流量控制](http://www.servicemesher.com/blog/raw-tcp-traffic-shaping-with-istio/) 8 | 9 | - [服务网格是中间件的终结者吗？](http://www.servicemesher.com/blog/does-the-service-mesh-spell-the-end-for-middleware/) 10 | 11 | - [istio-ui——一款开源的简易Istio UI的介绍和使用教程](http://www.servicemesher.com/blog/istio-ui-tutorial/) 12 | 13 | - [Kiali——Istio Service Mesh 的可观察性工具](http://www.servicemesher.com/blog/kiali-the-istio-service-mesh-observability-tool/) 14 | 15 | ## 新闻 16 | 17 | - [IBM 340亿美元收购 Red Hat](https://www.redhat.com/en/about/press-releases/ibm-acquire-red-hat-completely-changing-cloud-landscape-and-becoming-world%E2%80%99s-1-hybrid-cloud-provider)，再看[IBM云计算CTO讲述Istio项目的起源、分工及目标](http://www.servicemesher.com/blog/istio-aims-to-be-the-mesh-plumbing-for-containerized-microservices/)，IBM可能持续加大对开源社区的影响力。 18 | 19 | 本文归档到https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20181029-20181104.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #19 2018.10.29- 2018.11.04 2 | 3 | ## 博客 4 | 5 | - [服务网格的未来Part 2：Istio 1.0之后何去何从？](https://mp.weixin.qq.com/s/I7KnoLPbD2v8uR4IfMU05A) 6 | - [如何将云原生工作负载映射到Kubernetes中的控制器](https://mp.weixin.qq.com/s/46wq9RsA3tBUGj3MP3JrXA) 7 | - [云原生可移植性的神话](https://mp.weixin.qq.com/s/byvrClm8MqVeYKUnKKO82w) 8 | - [服务网格的未来Part 1：服务网格架构是必然趋势并愈加重要](https://mp.weixin.qq.com/s/sZlGF10Hppd2zRsbJVz8sw) 9 | - [Istio实战系列 - Envoy Proxy 构建分析](https://mp.weixin.qq.com/s/LEYBDT1yyjiTzpd5pUJKAw) 10 | - [蚂蚁金服 Service Mesh 实践探索](https://juejin.im/post/5bd90ea851882509c152f8d4) 11 | 12 | ## 活动 13 | 14 | - [IBM 课堂之年度大戏《Istio 系列》](https://mp.weixin.qq.com/s/CiAz2X3WPrs5Ika_aR7RfQ) 15 | 16 | 本文归档到https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20181105-20181111.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #20 2018.11.05- 2018.11.11 2 | 3 | ## 博客 4 | 5 | - [评估Kubernetes中的Serverless框架](https://juejin.im/post/5be3d99d6fb9a049bd41c8e6) 6 | 7 | - [Cilium——具备API感知的网络和安全性管理软件](https://juejin.im/post/5be39b656fb9a049ef2611f1) 8 | 9 | - [Cilium 1.3：支持Envoy、Cassandra和Memcached的Go语言扩展](https://juejin.im/post/5be11a1f6fb9a049d7472580) 10 | 11 | - [Istio Ingress Gateway中的Envoy配置解析](https://juejin.im/post/5bdfcfdce51d450558122db2) 12 | 13 | - [SRE 弹性能力：使用 Envoy 对应用进行速率限制](https://juejin.im/post/5bde72946fb9a04a0f649c76) 14 | 15 | ## 活动 16 | 17 | - [IBM 课堂之年度大戏《Istio 系列》](https://mp.weixin.qq.com/s/CiAz2X3WPrs5Ika_aR7RfQ) 18 | 19 | 本文归档到https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20181112-20181118.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #21 2018.11.12 - 2018.11.18 2 | 3 | ## 博客 4 | 5 | - [Envoy、gRPC 和速率限制](http://www.servicemesher.com/blog/envoy-grpc-and-rate-limiting/) 6 | - [Cilium 架构设计与概念解析](https://jimmysong.io/kubernetes-handbook/concepts/cilium-concepts.html) 7 | - [为什么要使用 Service Mesh？](http://www.servicemesher.com/blog/why-is-service-mesh/) 8 | - [Kubernetes（K8s）的无服务器框架的评估](http://www.servicemesher.com/blog/evaluation-of-serverless-frameworks-for-kbe/) 9 | 10 | ## 活动 11 | 12 | - [ServiceMesher社区成员聚首KubeCon&CloudNativeCon上海](https://mp.weixin.qq.com/s/_K8-mMnun8ZE7YDTWjepnw) 13 | 14 | 本文归档到https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20181119-20181125.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #22 2018.11.19 - 2018.11.25 2 | 3 | ## 博客 4 | 5 | - [Istio控制平面故障后会发生什么？](http://www.servicemesher.com/blog/istio-what-happens-when-control-plane-is-down/) 6 | 7 | - [Envoy service mesh、Prometheus和Grafana下的微服务监控](http://www.servicemesher.com/blog/microservices-monitoring-with-envoy-service-mesh-prometheus-grafana/) 8 | 9 | ## 活动 10 | 11 | - [第四届 Service Mesh Meetup 上海站圆满收官](https://tech.antfin.com/activities/2) 12 | 13 | 本文归档到https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20181126-20181202.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #23 2018.11.26 - 2018.12.02 2 | 3 | ## 博客 4 | 5 | - [Istio像鸟一样轻盈？微网关博客系列（4）](http://www.servicemesher.com/blog/istio-is-it-a-bird-microgateway-blog-series-part-4/) 6 | 7 | - [使用 Envoy 搭建 Service Mesh](http://www.servicemesher.com/blog/service-mesh-with-envoy-101/) 8 | 9 | - [Istio路由基础](http://www.servicemesher.com/blog/istio-routing-basics/) 10 | 11 | - [云原生世界中的隐形人如何拥抱 Istio](http://www.servicemesher.com/blog/invisible-men-in-the-world-of-cloudnative/) 12 | 13 | - [蚂蚁金服Service Mesh渐进式迁移方案](http://www.servicemesher.com/blog/ant-financial-service-mesh-adoption-plan/) 14 | 15 | - [当 Service Mesh 遇见 Event Mesh: Event-Driven 型企业新的架构层](http://www.servicemesher.com/blog/service-mesh-meet-event-mesh/) 16 | 17 | ## 活动 18 | 19 | - [第四届 Service Mesh Meetup 上海站圆满收官|查看视频回放和下载 PPT](https://tech.antfin.com/activities/2) 20 | 21 | ## 新闻 22 | 23 | - [亚马逊宣布正在开发 AWS 上的微服务 Service Mesh——App Mesh](https://aws.amazon.com/blogs/compute/introducing-aws-app-mesh-service-mesh-for-microservices-on-aws/) 24 | 25 | 本文归档到https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20181203-20181209.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #24 2018.12.03 - 2018.12.09 2 | 3 | ## 博客 4 | 5 | - [使用Istio和Envoy实践服务网格gRPC度量](http://www.servicemesher.com/blog/istio-envoy-grpc-metrics-winning-with-service-mesh-in-practice/) 6 | 7 | - [微服务通信的设计模式](http://www.servicemesher.com/blog/design-patterns-for-microservice-communication/) 8 | 9 | - [使用Istio和Envoy实践服务网格gRPC度量](http://www.servicemesher.com/blog/istio-envoy-grpc-metrics-winning-with-service-mesh-in-practice/) 10 | 11 | - [Serverless Jenkins 和 Jenkins X](http://www.servicemesher.com/blog/serverless-jenkins-with-jenkins-x/) 12 | 13 | - [蚂蚁金服Service Mesh新型网络代理的思考与实践](http://www.servicemesher.com/blog/microservice-with-service-mesh-at-ant-financial/) 14 | 15 | - [CentOS7官方Docker发行版现重大Bug可致Kubernetes中的健康检测探针失败并影响容器交互附临时解决方案](https://jimmysong.io/posts/docker-exec-bug-on-centos7/) 16 | 17 | 本文归档到https://github.com/servicemesher/trans 18 | 19 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20181210-20181216.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #25 2018.12.10 - 2018.12.16 2 | 3 | ## 博客 4 | 5 | - [Envoy中的数据统计](http://www.servicemesher.com/blog/envoy-stats/) 6 | 7 | - [构建无缝集成的gRPC-Web和Istio的云原生应用教程](http://www.servicemesher.com/blog/seamless-cloud-native-apps-with-grpc-web-and-istio/) 8 | 9 | - [使用Envoy和Jaeger实现分布式追踪](http://www.servicemesher.com/blog/distributed-tracing-with-envoy-service-mesh-jaeger/) 10 | 11 | - [如何从零开始编写一个Kubernetes CRD](http://www.servicemesher.com/blog/kubernetes-crd-quick-start/) 12 | 13 | - [从百家争鸣的微服务生态到服务网格](http://www.servicemesher.com/blog/from-fragmented-microservices-ecosystem-to-service-mesh/) 14 | 15 | 本文归档到https://github.com/servicemesher/trans 16 | 17 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20181217-20181223.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #26 2018.12.17- 2018.12.23 2 | 3 | ## 博客 4 | 5 | - [蚂蚁金服开源的Service Mesh Sidecar代理SOFAMosn发布0.4.0版本](https://github.com/alipay/sofa-mosn/blob/master/docs/CHANGELOG.md) 6 | - [Istio 中的服务和流量的抽象模型——为什么说Kubernetes service存在的意义仅剩下做服务发现](https://jimmysong.io/posts/istio-service-and-traffic-model/) 7 | - [Google 开源的Serverless 平台 Knative 简介](http://www.servicemesher.com/blog/knative-serverless-platform/) 8 | 9 | 本文归档到https://github.com/servicemesher/trans 10 | 11 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20181224-20181230.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #27 2018.12.24- 2018.12.30 2 | 3 | ## 博客 4 | 5 | - [Kubernetes资源管理概述](http://www.servicemesher.com/blog/kubernetes-resource-management/)，by 吴伟 6 | 7 | - [Github中式开源志异](http://www.servicemesher.com/blog/strange-stories-from-chinese-github-participants/)，by 我把玲玲打一顿 8 | 9 | - [理解 Istio Service Mesh 中 Envoy Sidecar 代理的路由转发](http://www.servicemesher.com/blog/envoy-sidecar-routing-of-istio-service-mesh-deep-dive/)，by 宋净超 10 | 11 | - [拥抱NFV，Istio 1.1 将支持多网络平面](http://www.servicemesher.com/blog/multi-network-interfaces-for-istio/)，by 赵化冰 12 | 13 | ## 活动 14 | 15 | - [第五届 Service Mesh Meetup 广州站报名](https://tech.antfin.com/activities/72) 16 | 17 | 本文归档到https://github.com/servicemesher/trans 18 | 19 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20181231-20190106.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #28 2018.12.30 - 2019.01.06 2 | 3 | ## 博客 4 | 5 | - [SuperGloo—服务网格编排平台](http://www.servicemesher.com/blog/supergloo-a-service-mesh-orchestrator/)，by 宋净超 6 | 7 | - [Knative：重新定义 serverless](http://www.servicemesher.com/blog/knative-redefine-serverless/)，by 敖小剑 8 | 9 | - [Kubernetes Ingress Controller的使用介绍及高可用落地](http://www.servicemesher.com/blog/kubernetes-ingress-controller-deployment-and-ha/)，by zhangguanzhang 10 | 11 | ## 活动 12 | 13 | - [第五届 Service Mesh Meetup 广州站圆满结束](https://tech.antfin.com/activities/72) 14 | 15 | 本文归档到https://github.com/servicemesher/trans 16 | 17 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190107-20190113.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #29 2019.01.07 - 2019.01.13 2 | 3 | ## 博客 4 | 5 | - [在网格的边缘试探——企业服务行业如何试水 Istio](http://www.servicemesher.com/blog/explore-at-the-edge-of-istio-service-mesh/)，by 崔秀龙 6 | 7 | - [全手动部署prometheus-operator监控Kubernetes集群遇到的坑](http://www.servicemesher.com/blog/prometheus-operator-manual/)，by 张馆长 8 | 9 | - [Istio 的数据平面 Envoy Proxy 配置详解](http://www.servicemesher.com/blog/envoy-proxy-config-deep-dive/)，by 宋净超 10 | 11 | - [Gloo——记一次失败的实验](https://blog.fleeto.us/post/gloo-amazing-gateway/)，by 崔秀龙 12 | 13 | ## 活动 14 | 15 | - [第五届 Service Mesh Meetup 广州站回顾](http://www.servicemesher.com/blog/service-mesh-meetup-guangzhou-20190106/) 16 | 17 | 本文归档到https://github.com/servicemesher/trans 18 | 19 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190211-20190217.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #30 2019.02.11 - 2019.02.17 2 | 3 | ## 博客 4 | 5 | - [CNCF年度报告解读（2018年）](http://www.servicemesher.com/blog/cncf-annual-report-2018-review/)，by 宋净超 6 | 7 | - [Kong mesh深度分析报告](http://www.servicemesher.com/blog/kong-mesh-analyse-report/)，by 单家骏 8 | 9 | - [腾讯云容器团队内部Istio专题分享](http://www.servicemesher.com/blog/istio-the-king-of-service-mesh/)，by 钟华 10 | 11 | - [【译】REST的替代者：Envoy+gRPC-Web](http://www.servicemesher.com/blog/envoy-and-grpc-web-a-fresh-new-alternative-to-rest/)，by Luc Perkins，李琪 译 12 | 13 | - [Service Mesh——后 Kubernetes 时代的微服务](http://www.servicemesher.com/blog/service-mesh-the-microservices-in-post-kubernetes-era/)，by 宋净超 14 | 15 | 16 | ## 活动 17 | 18 | - [Istio知识图谱活动](http://www.servicemesher.com/contact) 19 | 20 | 本文归档到https://github.com/servicemesher/trans 21 | 22 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190218-20190224.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #31 2019.02.18 - 2019.02.24 2 | 3 | ## 博客 4 | 5 | - [【译】Envoy架构师Matt Klein对Envoy线程模型的简介](http://www.servicemesher.com/blog/envoy-threading-model/)，by Matt Klein，王凯 译 6 | - [面向 Kubernetes 编程：Kubernetes 是下一代操作系统](http://www.servicemesher.com/blog/the-data-center-os-kubernetes/)，by 陈俊 7 | - [《深入浅出 Istio》读后感](http://www.servicemesher.com/blog/reading-istio-service-mesh-book/)，by 高松 8 | - [Service Mesh的2018年度总结](http://www.servicemesher.com/blog/service-mesh-summary-2018/)，by 敖小剑、崔秀龙、单家骏、宋净超、田晓亮、徐蓓、张超盟 9 | - [【译】Cilium 1.4 发布了，新功能一览](http://www.servicemesher.com/blog/cilium-1.4/)，by Cilium team，殷龙飞 译 10 | - [通过自定义Istio Mixer Adapter在JWT场景下实现用户封禁](http://www.servicemesher.com/blog/using-istio-mixer-adapter-to-check-jwt/)，by 高松 11 | 12 | 13 | ## 活动 14 | 15 | - [Istio知识图谱活动](https://github.com/servicemesher/istio-knowledge-map) 16 | 17 | 本文归档到https://github.com/servicemesher/trans 18 | 19 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190225-20190303.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #32 2019.02.25- 2019.03.03 2 | 3 | ## 博客 4 | 5 | - [【译】使用Istio打造微服务（第1部分）](http://www.servicemesher.com/blog/back-to-microservices-with-istio-p1/)，by Rinor Maloku，殷龙飞 译 6 | 7 | - [【译】Knative：精简代码之道](http://www.servicemesher.com/blog/knative-whittling-down-the-code/)，by Brian McClan，孙海洲 译 8 | 9 | - [【译】Istio——企业级微服务解决方案](http://www.servicemesher.com/blog/istio-kubernetes-service-mesh/)，by Luke Bond，李琪 译 10 | 11 | - [Knative Eventing in-memory-channel实现原理解析](http://www.servicemesher.com/blog/knative-eventing-in-memory-channel-deep-dive/)，by 牛秋霖 12 | 13 | 14 | ## 活动 15 | 16 | - [Istio知识图谱 v0.1 发布及社区图书孵化](http://www.servicemesher.com/blog/istio-knowledge-map-v0.1-release/) 17 | 18 | 本文归档到https://github.com/servicemesher/trans 19 | 20 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190304-20190310.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #33 2019.03.04 - 2019.03.10 2 | 3 | ## 博客 4 | 5 | 1. [【译】微服务断路器模式实现：Istio vs Hystrix](https://juejin.im/post/5c821798e51d457a7d431295)，by Nicolas Frankel，罗广明 译 6 | 2. [自定义Istio Mixer Adapter示例教程（附源码）](https://juejin.im/post/5c7f982ee51d454cde7d5015)，by 陈洪波 7 | 3. [【译】Istio中使用Prometheus进行应用程序指标度量](https://juejin.im/post/5c7f3396e51d4521346a5d72)，by Mete Atamel ，邱世达 8 | 4. [【译】Envoy Proxy构建控制平面指南](https://juejin.im/post/5c7c9a78e51d451d47634635)，by Christian Posta ，殷龙飞 9 | 10 | 11 | ## 活动 12 | 13 | 1. [Istio知识图谱 v0.1 发布及社区图书孵化活动发布](https://juejin.im/post/5c74b484518825626b76fc16) 14 | 2. 第一届 Service Mesh Day，3月29日，旧金山，http://servicemeshday.com/ 15 | 16 | 本文归档到https://github.com/servicemesher/trans 17 | 18 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190311-20190317.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #34 2019.03.11 - 2019.03.17 2 | 3 | ## 博客 4 | 5 | 1. [Istio 庖丁解牛一：组件概览](http://www.servicemesher.com/blog/istio-analysis-1/)，by 钟华 6 | 7 | 2. [Knative 入门系列1：knative 概述](http://www.servicemesher.com/blog/knative-overview/)，by Brian McClain & Bryan Friedman，陈家栋 译，宋净超、孙海洲、徐鹏、邱世达 审校 8 | 9 | 3. [Knative 入门系列2：serving 介绍](http://www.servicemesher.com/blog/knative-serving/)，by Brian McClain & Bryan Friedman，杨铁党 译，孙海洲、邱世达、宋净超、徐鹏 审校 10 | 11 | 4. [ServiceMesher社区推出合著Istio Handbook](https://juejin.im/post/5c88d1016fb9a049c43e87a8)，by ServiceMesher 社区 12 | 13 | 5. [Knative 入门系列3：Build 介绍](http://www.servicemesher.com/getting-started-with-knative/build.html)， 孙海洲 译，邱世达、陈冬、杨铁党、宋净超 审校 14 | 15 | 16 | ## 活动 17 | 18 | 1. 第一届 Service Mesh Day，3月29日，旧金山，http://servicemeshday.com/ 19 | 2. 第一届 SOFA Meetup，3月24日，北京，https://tech.antfin.com/activities/382 20 | 21 | ## 新闻 22 | 23 | 1. F5 收购 Nginx，https://www.nginx.com/blog/nginx-joins-f5/ 24 | 2. 基于Envoy和Istio的企业级服务网格解决方案初创公司[Tetrate.io](http://Tetrate.io)获得1250万美元融资， 25 | 3. 开创 Service Mesh 概念并开源 Linkerd 的服务网格初创公司 Buoyant 获得 Google Ventures 1000万美元投资，https://buoyant.io/2019/03/14/welcome-to-the-linkerd-party-google-ventures/ 26 | 27 | 本文归档到https://github.com/servicemesher/trans 28 | 29 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190318-20190324.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #35 2019.03.18 - 2019.03.24 2 | 3 | ## 博客 4 | 5 | 1. [Istio 1.1发布，中文文档同时释出](http://www.servicemesher.com/blog/istio-11/)，by 宋净超 6 | 7 | 2. [Istio1.1新特性之限制服务可见性](http://www.servicemesher.com/blog/istio-service-visibility/)，by 敖小剑 8 | 9 | 3. [Istio 庖丁解牛二：sidecar injector](http://www.servicemesher.com/blog/istio-analysis-2/)，by 钟华 10 | 11 | 4. [鸿沟前的服务网格—Istio 1.1 新特性预览](http://www.servicemesher.com/blog/service-mesh-and-chasm/)，by 崔秀龙 12 | 13 | 5. [Istio 服务注册插件机制代码解析](http://www.servicemesher.com/blog/istio-pilot-service-registry-code-analysis/)，by 赵化冰 14 | 15 | 6. [【译】手工打造像Istio中一样的Sidecar代理](http://www.servicemesher.com/blog/hand-crafting-a-sidecar-proxy-like-istio/)，by Venil Noronha，邱世达 译 16 | 17 | 18 | ## 活动 19 | 20 | 1. 第一届 SOFA Meetup 暨 SOFA 开源一周年活动，3月24日，北京，https://tech.antfin.com/activities/382 21 | 22 | 本文归档到https://github.com/servicemesher/trans 23 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190325-20190331.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #35 2019.03.25 - 2019.03.31 2 | 3 | ## 博客 4 | 5 | 1. 使用Istio打造微服务（第2部分）——认证和授权，，by Rinor Maloku，殷龙飞 译 6 | 7 | 2. Istio安全之服务间访问控制RBAC，，by 陈洪波 8 | 9 | 3. 为 Envoy 赋能——如何基于 Envoy 构建一个多用途控制平面，http://www.servicemesher.com/blog/building-a-control-plane-for-envoy/>，by Idit Lavine，孙海洲 10 | 11 | 4. Prometheus监控Kubernetes系列1——监控框架，，by 罗佳豪 12 | 13 | 5. Prometheus监控Kubernetes系列2——监控部署，，by 罗佳豪 14 | 15 | 本文归档到https://github.com/servicemesher/trans 16 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190401-20190407.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #36 2019.04.01 - 2019.04.07 2 | 3 | ## 博客 4 | 5 | 1. 你真的需要服务网格吗？，by Owen Garrett， 马若飞 译 6 | 2. Istio 庖丁解牛三：galley，，by 钟华 7 | 3. 熔断与异常检测在 Istio 中的应用，，by 杨传胜 8 | 4. Prometheus监控Kubernetes系列3——业务指标采集，，by 罗佳豪 9 | 10 | 本文归档到https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190408-20190414.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #37 2019.04.08 - 2019.04.14 2 | 3 | ## 博客 4 | 5 | 1. Istio 学习笔记：Istio CNI 插件，，by 陈鹏 6 | 7 | 2. Knative 入门系列5：Knative 安装，，by Brian McClain & Bryan Friedman，李寿景 译，孙海洲、邱世达、徐鹏 审校 8 | 9 | 3. 为 Envoy 构建控制平面指南第3部分：领域特定配置，，by Christian Posta，孙海洲 译 10 | 11 | 4. Istio Sidecar 注入过程解密，，by Manish Chugtu，崔秀龙 译 12 | 13 | 5. MicroProfile——为Istio创建的微服务编程模型，，by Emily Jiang，罗广明 译 14 | 15 | 本文归档到 https://github.com/servicemesher/trans 16 | 17 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190415-20190421.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #38 2019.04.15 - 2019.04.21 2 | 3 | ## 博客 4 | 5 | 1. 选择FaaS还是微服务？http://www.servicemesher.com/blog/faas-vs-microservices/ ，by Christian Posta，李琪 译 6 | 2. 基于Flagger和Istio实现自动化金丝雀部署，http://www.servicemesher.com/blog/automated-canary-deployments-with-flagger-and-istio ，by Stefan Prodan，宋歌 译 7 | 3. Kubernetes dashboard在ssl的各种场景下的手动部署，http://www.servicemesher.com/blog/general-kubernetes-dashboard/ ，by 张馆长 8 | 4. Cloud Native Weekly第一期，http://www.servicemesher.com/blog/cloud-native-weekly-01/ ，by 张磊 临石 禅鸣 至简 宋净超 9 | 5. Knative 入门之 Knative 使用，http://www.servicemesher.com/getting-started-with-knative/using-knative.html ，by Brian McClain & Bryan Friedman，殷龙飞 译 10 | 6. Knative 入门之 Knative 实战演练，http://www.servicemesher.com/getting-started-with-knative/putting-it-all-together.html ，by Brian McClain & Bryan Friedman，张晓鹏 译 11 | 12 | ## 活动 13 | 14 | 1. 中国科学院计算技术研究所CCF TF 技术前线第15期“Cloud Native 云原生时代的架构”研讨会上，字节跳动基础架构研发工程师**成国柱**做了《Service Mesh在字节跳动的落地实践》的主题粉分享，PPT 会在后续公布。 15 | 16 | 本文归档到 https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190422-20190428.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #39 2019.04.22 - 2019.04.28 2 | 3 | ## 博客 4 | 5 | 1. Kubernetes Ingress Controller的使用介绍及高可用落地，http://www.servicemesher.com/blog/kubernetes-ingress-controller-deployment-and-ha/ ，by 张馆长 6 | 7 | 2. 云原生生态周报（Cloud Native Weekly）第2期，http://www.servicemesher.com/blog/cloud-native-weekly-02/ ，by 云原生编辑部 8 | 9 | 3. 导致云原生微服务系统开发灾难性的8件事，http://www.servicemesher.com/blog/eight-things-leads-to-developing-catastrophic-cloud-native-microservices-system/ ，by CHRISTINA の J老闆，马若飞 译 10 | 11 | 4. Istio 监控详解，http://www.servicemesher.com/blog/istio-monitoring-explained/ ，by Ferando Ripoll，罗广明 译 12 | 13 | 5. 为 Envoy 构建控制面指南第4部分：构建的可扩展性，http://www.servicemesher.com/blog/guidance-for-building-a-control-plane-for-envoy-part-4-build-for-extensibility/ ，by Christian Posta，孙海洲 译 14 | 15 | 6. 《Knative 入门》中文版发布|附PDF 下载，https://github.com/servicemesher/getting-started-with-knative/releases ，by ServiceMesher 社区 16 | 17 | 本文归档到 https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190429-20190505.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #40 2019.04.29 - 2019.05.05 2 | 3 | ## 博客 4 | 5 | 1. 服务网格时代：Istio在混合云未来扮演的角色，http://www.servicemesher.com/blog/the-service-mesh-era-istios-role-in-the-future-of-hybrid-cloud/ ，by Magan O'Keefe，王夕宁 译 6 | 7 | ## 活动 8 | 9 | 1. ServiceMesher 社区邮件组：https://groups.google.com/forum/#!forum/servicemesher 10 | 11 | 本文归档到 https://github.com/servicemesher/trans -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190506-20190512.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #41 2019.05.06 - 2019.05.12 2 | 3 | ## 博客 4 | 5 | 1. Google Traffic Director详细介绍，http://www.servicemesher.com/blog/google-traffic-director-detail/ ，by 敖小剑 6 | 2. Google混合云多云平台Anthos Config Management产品设计分析，http://www.servicemesher.com/blog/anthos-config-management-intro/ ，by 钟成 7 | 3. CNCF正在筹建通用数据平面API工作组，以制定数据平面的标准API，http://www.servicemesher.com/blog/cncf-udpa-wg/ ，by 敖小剑 8 | 4. 云原生生态周报（Cloud Native Weekly）第3期，http://www.servicemesher.com/blog/cloud-native-weekly-03/ ，by 云原生编辑部 9 | 5. Envoy、服务网格和可观察性之企业最佳实践，http://www.servicemesher.com/blog/envoy-service-mesh-and-observability-best-practices-for-enterprises/ ，by Stela Udovicic，张新峰 译 10 | 11 | ## 活动 12 | 13 | 1. 为了便于社区成员之间交流欢迎加入 ServiceMesher 社区邮件组：https://groups.google.com/forum/#!forum/servicemesher 14 | 2. KubeCon&CloudNativeCon + Open Source Summit 同场活动 SOFAStack Cloud Native Workshop：https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/ 15 | 16 | 本文归档到 https://github.com/servicemesher/trans 17 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190513-20190519.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #42 2019.05.13 - 2019.05.19 2 | 3 | ## 博客 4 | 5 | 1. Solo.io打造的Gloo——Knative中Istio的替代方案，http://www.servicemesher.com/blog/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative/ ，by Diógenes Rettori，孙海洲 译 6 | 7 | 2. API Gateway的身份认同危机，http://www.servicemesher.com/blog/api-gateways-are-going-through-an-identity-crisis/ ，by Christian Posta，周雨青 译 8 | 9 | 3. Google Cloud Run详细介绍，http://www.servicemesher.com/blog/google-cloud-run-intro/ ，by 敖小剑 10 | 11 | ## 活动 12 | 13 | 1. ServiceMesher 社区治理委员会第一次线下研讨会 5 月 18 日在北京召开，宋净超、罗广明、殷龙飞、孙海洲、张成参加了会议，本次会议就社区发展与治理展开了深入的讨论。 14 | 2. KubeCon&CloudNativeCon + Open Source Summit 同场活动 SOFAStack Cloud Native Workshop 报名：https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/ 15 | 16 | 本文归档到 https://github.com/servicemesher/trans 17 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190520-20190526.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #43 2019.05.20 - 2019.05.26 2 | 3 | ## 博客 4 | 5 | 1. Google Traffic Director详细介绍，http://www.servicemesher.com/blog/google-traffic-director-detail/ ，by 敖小剑 6 | 7 | 2. 如何为服务网格选择入口网关？http://www.servicemesher.com/blog/how-to-pick-gateway-for-service-mesh/ ，by 赵化冰 8 | 9 | 3. 微服务中的熔断简介及工作原理详解（第2部分），http://www.servicemesher.com/blog/preventing-systemic-failure-circuit-breaking-part-2/ ，by Yu-Han Lin，罗广明 译 10 | 11 | 4. 基于 Kubernetes 的 Service Mesh 简介，http://www.servicemesher.com/blog/kubernetes-service-mesh/ ，by Alen Komljen，张成 译 12 | 13 | 5. Istio 庖丁解牛四：pilot discovery，http://www.servicemesher.com/blog/istio-analysis-4/ ，by 钟华 14 | 15 | ## 活动 16 | 17 | 1. 5 月 25 日 Kubernetes and Cloud Native Meetup 上海站，蚂蚁金服高级技术专家敖小剑分享了《Service Mesh发展趋势：云原生中流砥柱》 18 | 2. 5 月 26 日 SOFA Meetup #2 上海站，使用 SOFAStack 快速构建微服务，https://tech.antfin.com/community/activities/576 19 | 3. KubeCon&CloudNativeCon + Open Source Summit 同场活动 SOFAStack Cloud Native Workshop 报名：https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/ 20 | 21 | 本文归档到 https://github.com/servicemesher/trans 22 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190527-20190602.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #44 2019.05.27 - 2019.06.02 2 | 3 | ## 博客 4 | 5 | 1. Istio遥测和可观察性探索，http://www.servicemesher.com/blog/exploring-istio-telemetry-and-observability/ ，by Marton Sereg，张成 译 6 | 7 | 2. Service Mesh发展趋势：云原生中流砥柱，http://www.servicemesher.com/blog/201905-servicemesh-development-trend/ ，by 敖小剑 8 | 9 | 3. 使用Kubernetes，Istio和Helm实现金丝雀发布，http://www.servicemesher.com/blog/canary-release-strategy-using-kubernetes-istio-and-helm/ ，by Maninderjit (Mani) Bindra，宋歌 译 10 | 11 | 4. 部署Envoy代理来为Monzo提速，http://www.servicemesher.com/blog/deploying-envoy-proxy/ ，by Suhail Patel，孙海洲 译 12 | 13 | 5. 基于Go、gRPC和Protobuf的微服务的Istio可观察性，http://www.servicemesher.com/blog/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/ ，by Gary Stafford，马若飞 译 14 | 15 | ## 活动 16 | 17 | 1. KubeCon&CloudNativeCon + Open Source Summit 同场活动 SOFAStack Cloud Native Workshop 报名：https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/ 18 | 19 | 本文归档到 https://github.com/servicemesher/trans 20 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190603-20190609.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #45 2019.06.03 - 2019.06.09 2 | 3 | ## 博客 4 | 5 | 1. 容器、微服务和服务网格简史，http://www.servicemesher.com/blog/containers-microservices-service-meshes/ ，by Jérôme Petazzoni，罗广明 译 6 | 7 | 2. Service Mesh Interface 详细介绍，https://skyao.io/post/201906-service-mesh-interface-detail/ ，by 敖小剑 8 | 9 | 3. 介绍一个小工具：Ksniff，https://blog.fleeto.us/post/intro-ksniff/ ，by 崔秀龙 10 | 11 | ## 活动 12 | 13 | 1. KubeCon&CloudNativeCon + Open Source Summit 同场活动 SOFAStack Cloud Native Workshop 报名：https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/ 14 | 15 | 本文归档到 https://github.com/servicemesher/trans 16 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190610-20190616.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #46 2019.06.10 - 2019.06.16 2 | 3 | ## 博客 4 | 5 | 1. 使用Jenkins X实现ChatOps，http://www.servicemesher.com/blog/implementing-chatops-with-jenkins-x/ ，by Viktor Farcic，孙海洲 译 6 | 7 | ## 活动 8 | 9 | 1. KubeCon&CloudNativeCon + Open Source Summit 同场活动 SOFAStack Cloud Native Workshop 报名：https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/ 10 | 11 | 本文归档到 https://github.com/servicemesher/trans 12 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190617-20190623.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #47 2019.06.17 - 2019.06.23 2 | 3 | ## 活动 4 | 5 | 1. KubeCon&CloudNativeCon + Open Source Summit 同场活动 SOFAStack Cloud Native Workshop 报名：https://www.lfasiallc.com/events/kubecon-cloudnativecon-china-2019/co-located-events/ 6 | 7 | 本文归档到 https://github.com/servicemesher/trans 8 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190624-20190630.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #48 2019.06.24 - 2019.06.30 2 | 3 | ## 活动 4 | 5 | 1. 蚂蚁金服 Service Mesh 落地实践与挑战 | GIAC 实录：http://sina.lt/gtDa 6 | 2. 五小时构建云原生电商平台 | KubeCon SOFAStack Cloud Native Workshop 详解：http://sina.lt/gtCY 7 | 3. KubeCon China 2019 上海 ServiceMesher 社区成员再聚首 8 | 9 | 本文归档到 https://github.com/servicemesher/trans 10 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190701-20190707.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #49 2019.07.01 - 2019.07.07 2 | 3 | ## 博客 4 | 5 | 1. 开源，社区与朋友们-2019 KubeCon + ClondNativeCon + Open Source Summit有感，by 赵化冰，https://www.servicemesher.com/blog/kubecon-cncf-oss-2019/ 6 | 7 | 2. Prow 快速入门向导，https://www.servicemesher.com/blog/prow-quick-start-guide/ ，by 张新峰 8 | 9 | 3. 为Envoy构建控制面指南第2部分：识别组件，https://www.servicemesher.com/blog/guidance-for-building-a-control-plane-for-envoy-part-2-identify-components/ ，by Christian Posta，张成 译 10 | 11 | 4. Envoy功能点详解之异常点检测，https://www.servicemesher.com/blog/envoy-feature-explain-outlier-detection/ ，by 罗广明 12 | 13 | 本文归档到 https://github.com/servicemesher/trans 14 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190707-20190714.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #50 2019.07.08 - 2019.07.14 2 | 3 | ## 博客 4 | 5 | 1. 洞若观火：使用OpenTracing增强Istio的调用链跟踪-篇一，https://www.servicemesher.com/blog/using-opentracing-with-istio-part-1/ ，by 赵化冰 6 | 7 | 1. 深入了解Cilium多集群，https://www.servicemesher.com/blog/deep-dive-into-cilium-multi-cluster/ ，by Cilium team，陆培尔 译 8 | 9 | ## 活动 10 | 11 | 1. 【线上直播】SOFAChannel#7：扩展 Kubernetes 实现金融级云原生发布部署 - 自定义资源 CAFEDeployment 的背景、实现和演进，https://www.sofastack.tech/activities/sofa-channel-7/ ，by 枫晟 蚂蚁金服 SOFAStack-CAFE 云应用引擎 容器应用服务研发负责人 12 | 2. 【Service Mesh Meetup 强势回归】第 6 届再度登陆广州，暂定 8 月 11 日（星期日），欢迎大家提交演讲 topic 13 | 3. 向 ServiceMesher 社区投稿请访问 https://github.com/servicemesher/website 14 | 15 | 16 | 本文归档到 https://github.com/servicemesher/trans 17 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190715-20190721.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #51 2019.07.15 - 2019.07.21 2 | 3 | ## 博客 4 | 5 | 1. 洞若观火：使用OpenTracing增强Istio的调用链跟踪-篇二，https://www.servicemesher.com/blog/using-opentracing-with-istio-part-2/ ，by 赵化冰 6 | 7 | 1. Consul Service Mesh的7层网络可观察性，https://www.servicemesher.com/blog/layer-7-observability-with-consul-service-mesh/ ，by The Consul Team，张成 译 8 | 9 | 1. GitOps与ChatOps的落地实践，https://www.servicemesher.com/blog/gitops-and-chatops/ ，by 郭旭东 10 | 11 | ## 活动 12 | 13 | 2. 第 6 届 Service Mesh Meetup 将于 8 月 11 日（星期日）再次登临广州，详细信息及报名方式敬请关注 14 | 3. 向 ServiceMesher 社区投稿请访问 https://github.com/servicemesher/website 15 | 16 | ## 社区官网 17 | 18 | 1. 社区官网集成了 Gitalk 留言评论功能，使用 GitHub 账号登录即可评论，感谢[陆培尔](https://github.com/shinji3887)提交的 PR。 19 | 20 | 21 | ServiceMesher 社区周报归档在 https://github.com/servicemesher/weekly 22 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190722-20190728.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #52 2019.07.22 - 2019.07.28 2 | 3 | ## 博客 4 | 5 | 1. 洞若观火：使用OpenTracing增强Istio的调用链跟踪-篇二，https://www.servicemesher.com/blog/using-opentracing-with-istio-part-2/ ，by 赵化冰 6 | 7 | 8 | ## 活动 9 | 10 | 1. 第 6 届 Service Mesh Meetup 将于 8 月 11 日（星期日）再次登临广州，报名地址：https://tech.antfin.com/community/activities/781 11 | 1. Service Mesh Meetup 当天下午同一地点 SOFA Meetup #3，报名地址：https://tech.antfin.com/community/activities/779 12 | 13 | ## 社区治理 14 | 15 | 1. ServiceMesher 社区治理委员会成立，首批成员：罗广明（百度）、马若飞（FreeWheel）、邱世达（博云）、宋净超（蚂蚁金服）、孙海洲（中科院计算所）、殷龙飞（北控三兴）、赵化冰（中兴通讯）、钟华（腾讯） 16 | 1. 社区官网自动化CI/CD配置完成，使用 Kubernetes prow 实现机器人，感性张新峰的指导，查看页面：https://prow.servicemesher.com/ 17 | 18 | 19 | ServiceMesher 社区周报归档在 https://github.com/servicemesher/weekly 20 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190729-20190804.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #53 2019.07.29 - 2019.08.04 2 | 3 | ## 博客 4 | 5 | 1. Istio 庖丁解牛五：多集群网格实现分析，https://www.servicemesher.com/blog/istio-analysis-5/ ，by 钟华 6 | 7 | 1. 服务网格的三个技术优势及其运维局限-第1部分，https://www.servicemesher.com/blog/service-mesh-istio-limits-and-benefits-part-1/ ，by Tobias Kunze，罗广明 译 8 | 9 | 1. 服务网格的三个技术优势及其运维局限-第2部分，https://www.servicemesher.com/blog/service-mesh-istio-limits-and-benefits-part-2/ ，by Tobias Kunze，罗广明 译 10 | 11 | ## 活动 12 | 13 | 1. 第 6 届 Service Mesh Meetup 将于 8 月 11 日（星期日）再次登临广州，报名地址：https://tech.antfin.com/community/activities/781 14 | 1. Service Mesh Meetup 当天下午同一地点 SOFA Meetup #3，报名地址：https://tech.antfin.com/community/activities/779 15 | 16 | ## 社区投稿 17 | 18 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 19 | 20 | 21 | ServiceMesher 社区周报归档在 https://github.com/servicemesher/weekly 22 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190805-20190811.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #54 2019.08.05 - 2019.08.11 2 | 3 | ## 博客 4 | 5 | 1. 运行在Istio之上的Apache Kafka——基准测试，https://www.servicemesher.com/blog/running-apache-kafka-over-istio-benchmark/ ，by Balint Molnar，马若飞 译 6 | 7 | 1. 构建云原生微服务网关-篇一：Ambassador，https://www.servicemesher.com/blog/cloud-native-api-gateway-part-1/ ，by 陆培尔 8 | 9 | 1. Istio 庖丁解牛六：多集群网格应用场景，https://www.servicemesher.com/blog/istio-analysis-6/ ，by 钟华 10 | 11 | ## 活动 12 | 13 | 1. 8 月 11 日（星期日），第 6 届 Service Mesh Meetup 在广州成功举办，活动回顾及幻灯片下载将在本周陆续放出。 14 | 1. 8 月 11 日（星期日），Service Mesh Meetup 同场的第三届 SOFA Meetup 活动回顾敬请关注：https://tech.antfin.com/community/activities/779 15 | 16 | ## 社区投稿 17 | 18 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 19 | 20 | 21 | ServiceMesher 社区周报归档在 https://github.com/servicemesher/weekly 22 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190812-20190818.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #55 2019.08.12 - 2019.08.18 2 | 3 | ## 博客 4 | 5 | 1. 第六届 Service Mesh Meetup 广州站回顾，，by 宋净超 6 | 7 | ## 社区投稿 8 | 9 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 10 | 11 | 12 | ServiceMesher 社区周报归档在 https://github.com/servicemesher/weekly 13 | 14 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190819-20190825.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #56 2019.08.19 - 2019.08.25 2 | 3 | ## 博客 4 | 5 | 1. 微服务的设计模式，https://www.servicemesher.com/blog/design-patterns-for-microservices/ ，by Madhuka Udantha，崔秀龙 译 6 | 7 | 2. 实现Kubernetes Operator的新方式：Python，https://www.servicemesher.com/blog/kubernetes-operator-in-python/ ，by Flant staff，罗广明 译 8 | 9 | 3. 基于Flux项目的云原生GitOps实践，https://www.servicemesher.com/blog/flux-get-start-easy/ ，by 张哲然 10 | 11 | ## 社区投稿 12 | 13 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 14 | 15 | 16 | ServiceMesher 社区周报归档在 https://github.com/servicemesher/weekly 17 | 18 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190826-20190901.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #57 2019.08.26 - 2019.09.01 2 | 3 | ## 博客 4 | 5 | 1. 使用Knative作为API聚合层的实践，https://www.servicemesher.com/blog/using-knative-as-api-aggregator-layer/ ，by 高松 6 | 7 | 2. 容器化到容器编排之旅，https://www.servicemesher.com/blog/journey-from-containerization-to-orchestration-and-beyond/ ，by Ivan Velichko，马若飞 译 8 | 9 | ## 社区投稿 10 | 11 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 12 | 13 | 14 | ServiceMesher 社区周报归档在 https://github.com/servicemesher/weekly 15 | 16 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190902-20190908.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #58 2019.09.02 - 2019.09.08 2 | 3 | ## 博客 4 | 5 | 1. 全面进化：Kubernetes CRD 1.16 GA前瞻，https://www.servicemesher.com/blog/kubernetes-1.16-crd-ga-preview/ ，by Min Kim 6 | 7 | 2. Contour 学习笔记（一）：使用 Contour 接管 Kubernetes 的南北流量，https://www.servicemesher.com/blog/use-envoy-as-a-kubernetes-ingress/ ，by 杨传胜 8 | 9 | 3. Kubernetes上的Service Mesh实践：用EnvoyFilter扩展Istio，https://www.servicemesher.com/blog/using-envoyfilter-extend-istio/ ，by 王昌宇 10 | 11 | ## 社区投稿 12 | 13 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 14 | 15 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190909-20190915.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #59 2019.09.09 - 2019.09.15 2 | 3 | ## 博客 4 | 5 | 1. 服务网格 Kuma 爬过了 Kubernetes 这座大山，https://www.servicemesher.com/blog/kong-open-sources-kuma-the-universal-service-mesh/ ，by Dan Meyer，罗广明 译 6 | 7 | 1. AWS App Mesh - 云应用的服务网格，https://www.servicemesher.com/blog/aws-app-mesh-application-level-networking-for-cloud-applications/ ，by Jeff Barr，马若飞 译 8 | 9 | 1. 使用spring boot+kubernetes构建完整微服务平台，https://www.servicemesher.com/blog/201909-build-full-micro-service-platform-by-spring-boot-with-kubernetes/ ，by 陆培尔 10 | 11 | 1. Service Mesh 发展趋势(续)：棋到中盘路往何方 | Service Mesh Meetup 实录，https://www.sofastack.tech/blog/service-mesh-development-trend-2/ ，by 敖小剑 12 | 13 | ## 社区投稿 14 | 15 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 16 | 17 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190916-20190922.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #60 2019.09.16 - 2019.09.22 2 | 3 | ## 博客 4 | 5 | 1. 构建 Kubernetes 集群——合理选择工作节点数量和大小，https://www.servicemesher.com/blog/architecting-kubernetes-clusters-choosing-a-worker-node-size/ ，by Daniel Weibel，邱世达 译 6 | 1. 使用Django、Prometheus 和 Kubernetes 定制应用指标，https://www.servicemesher.com/blog/custom-application-metrics-with-django-prometheus-and-kubernetes/ ，by Bobby Steinbach，马若飞 译 7 | 8 | ## 社区投稿 9 | 10 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 11 | 12 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190923-20190929.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #61 2019.09.23 - 2019.09.29 2 | 3 | ## 博客 4 | 5 | 1. 你必知的 Kubernetes 自动缩放，https://www.servicemesher.com/blog/k8s-autoscaling-all-you-need-to-know/ ，by Juan Ignacio Giro，段访 译 6 | 7 | ## 社区投稿 8 | 9 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 10 | 11 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20190930-20191006.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #62 2019.09.30 - 2019.10.06 2 | 3 | ## 博客 4 | 5 | 本周国庆假期，无发布。 6 | 7 | ## 社区投稿 8 | 9 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 10 | 11 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20191007-20191014.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #63 2019.10.07 - 2019.10.13 2 | 3 | ## 博客 4 | 5 | 1. Istio熔断器解析，https://www.servicemesher.com/blog/istio-circuit-breaking/ ，by Laszlo Bence Nagy，马若飞 译 6 | 7 | ## 活动 8 | 9 | 【第一次社区治理线上会议召开】 10 | 11 | 10 月 12 日晚，ServiceMesher 社区治理委员会第一次线上会议召开，宋净超主持了会议，罗广明、孙海洲、邱世达、钟华、陈冬、马若飞、殷龙飞、赵化冰参加了会议，会议传达了 ServiceMesher 社区现状并讨论了社区下一步工作，确立了以 Service Mesh 为社区核心技术并谨慎扩展到云原生领域的方针。 12 | 13 | 【第七届Service Mesh Meetup成都站预告】 14 | 15 | 第七届 Service Mesh Meetup 将于本月底在成都举办，报名信息请关注群内公告或关注 ServiceMesher 社区公众号。 16 | 17 | ## 社区投稿 18 | 19 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 20 | 21 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20191015-20191020.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #64 2019.10.14 - 2019.10.20 2 | 3 | ## 博客 4 | 5 | 1. 基于自定义Istio指标的Pod水平自动缩放，https://www.servicemesher.com/blog/20190910-horizontal-pod-autoscaling-based-on-custom-istio-metrics/ ，by Sandor Mayyari，张成 译 6 | 7 | 2. AWS App Mesh vs Istio，https://www.servicemesher.com/blog/compare-appmesh-with-istio ，by 马若飞 8 | 9 | ## 活动 10 | 11 | 【第七届Service Mesh Meetup成都站报名】 12 | 13 | 第七届 Service Mesh Meetup 将于10 月 26 日星期六在成都蚂蚁 C 空间举办，报名地址：https://www.huodongxing.com/event/2514724877500 。 14 | 15 | ## 社区投稿 16 | 17 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 18 | 19 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20191021-20191027.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #65 2019.10.21 - 2019.10.27 2 | 3 | ## 【博客】 4 | 5 | 1. ## Istio Pilot代码深度解析，https://www.servicemesher.com/blog/201910-pilot-code-deep-dive/ ，by 赵化冰 6 | 7 | 2. ## 企业组织中采用服务网格的挑战，https://www.servicemesher.com/blog/challenges-of-adopting-service-mesh-in-enterprise-organizations/ ，by Christian Posta，罗广明 译 8 | 9 | ## 【活动】 10 | 11 | 第七届 Service Mesh Meetup 于10 月 26 日星期六在成都蚂蚁 C 空间成功举办，现场上百人参加，现场视频回放及讲师 PPT 下载请关注本群通知。 12 | 13 | ## 【社区投稿】 14 | 15 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 16 | 17 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20191029-20191103.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #66 2019.10.28 - 2019.11.03 2 | 3 | ## 【博客】 4 | 5 | 1. #### Service Mesh是下一代SDN吗？https://www.servicemesher.com/blog/201910-what-can-service-mesh-learn-from-sdn/ ，by 赵化冰 6 | 7 | 2. #### Linkerd2 proxy destination 学习笔记，https://www.servicemesher.com/blog/linkerd2-proxy-destination-analysis/ by 哗啦啦 Mesh 团队 8 | 9 | ## 【活动】 10 | 11 | Istio 官网中文翻译团队成员开始招募，请查看Istio官方文档翻译指导手册，https://github.com/servicemesher/istio-official-translation 12 | 13 | ## 【社区投稿】 14 | 15 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 16 | 17 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20191104-20191110.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #67 2019.11.04 - 2019.11.10 2 | 3 | ## 【博客】 4 | 5 | 1. #### Linkerd2 proxy tap 学习笔记，https://www.servicemesher.com/blog/linkerd2-proxy-tap-analysis/ ，by 哗啦啦 Mesh 团队 6 | 7 | ## 【活动】 8 | 9 | Istio 官网翻译活动正在进行中，参与活动请访问，https://github.com/servicemesher/istio-official-translation 10 | 11 | ## 【社区投稿】 12 | 13 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 14 | 15 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20191111-20191117.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #68 2019.11.11 - 2019.11.17 2 | 3 | ## 【活动】 4 | 5 | 1. Istio 官网翻译活动正在进行中，参与活动请访问，https://github.com/servicemesher/istio-official-translation 6 | 7 | 1. 第八届 Service Mesh Meetup 特别场：Kubernetes & Cloud Native X Service Mesh Meetup，https://www.servicemesher.com/blog/k8s-cloud-native-service-mesh-meetup/ 8 | 9 | ## 【社区投稿】 10 | 11 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 12 | 13 | -------------------------------------------------------------------------------- /content/service-mesh-weekly-20191118-20191124.md: -------------------------------------------------------------------------------- 1 | # Service Mesh Weekly #69 2019.11.18 - 2019.11.24 2 | 3 | ## 【博客】 4 | 5 | 1. 如何降低Istio服务网格中Envoy的内存开销？https://www.servicemesher.com/blog/201911-envoy-memory-optimize/ ，by 赵化冰 6 | 7 | ## 【活动】 8 | 9 | 1. 第八届 Service Mesh Meetup 特别场：Kubernetes & Cloud Native X Service Mesh Meetup，https://www.servicemesher.com/blog/k8s-cloud-native-service-mesh-meetup/ 10 | 11 | ## 【社区投稿】 12 | 13 | 投稿请访问 https://github.com/servicemesher/website 提交 issue。 14 | 15 | -------------------------------------------------------------------------------- /docker/circleci/Dockerfile: -------------------------------------------------------------------------------- 1 | FROM alpine:3.9 2 | 3 | MAINTAINER SataQiu <1527062125@qq.com> 4 | 5 | RUN apk add --no-cache bash git curl jq 6 | 7 | RUN apk add --no-cache nodejs-current-npm && \ 8 | npm install -g markdown-spellcheck 9 | 10 | RUN apk add --no-cache ruby ruby-dev ruby-rdoc && \ 11 | gem install mdl 12 | 13 | -------------------------------------------------------------------------------- /mdl_style.rb: -------------------------------------------------------------------------------- 1 | all 2 | rule 'MD002', :level => 2 3 | rule 'MD007', :indent => 4 4 | rule 'MD010', :code_blocks => false 5 | rule 'MD013', :line_length => 160, :code_blocks => false, :tables => false 6 | rule 'MD026', :punctuation => ".,;:!" 7 | exclude_rule 'MD002' 8 | exclude_rule 'MD010' 9 | exclude_rule 'MD013' 10 | exclude_rule 'MD014' 11 | exclude_rule 'MD030' 12 | exclude_rule 'MD032' 13 | exclude_rule 'MD033' 14 | exclude_rule 'MD036' 15 | exclude_rule 'MD041' 16 | exclude_rule 'MD046' 17 | -------------------------------------------------------------------------------- /scripts/lint_site.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | FAILED=0 4 | 5 | echo -ne "mdspell " 6 | mdspell --version 7 | echo -ne "mdl " 8 | mdl --version 9 | 10 | # This performs spell checking and style checking over changed markdown files 11 | check_pull_request_content() { 12 | 13 | # only check pull request, skip others 14 | if [[ -z $CIRCLE_PULL_REQUEST ]]; then 15 | echo "Skip, only check pull request." 16 | exit 0 17 | fi 18 | 19 | # get changed files of this PR 20 | CIRCLE_PR_NUMBER=${CIRCLE_PULL_REQUEST##*/} 21 | OWNER=$(echo $CIRCLE_PULL_REQUEST | cut -d / -f 4) 22 | REPO=$(echo $CIRCLE_PULL_REQUEST | cut -d / -f 5) 23 | URL="https://api.github.com/repos/$OWNER/$REPO/pulls/$CIRCLE_PR_NUMBER/files" 24 | 25 | echo 26 | echo "Getting list of changed markdown files..." 27 | CHANGED_MARKDOWN_FILES=( $(curl -s -X GET -G $URL | jq -r '.[] | select(.status != "removed") | select(.filename | endswith(".md")) | .filename') ) 28 | echo "Total changed markdown files: ${#CHANGED_MARKDOWN_FILES[@]}" 29 | echo ${CHANGED_MARKDOWN_FILES[@]} 30 | 31 | if [[ "${#CHANGED_MARKDOWN_FILES[@]}" != "0" ]]; then 32 | echo 33 | echo "Check spell (optional)..." 34 | echo 35 | mdspell --en-us --ignore-acronyms --ignore-numbers --no-suggestions --report ${CHANGED_MARKDOWN_FILES[@]} 36 | if [[ "$?" != "0" ]]; then 37 | echo 38 | echo "[WARNING]: Spell check failed. Feel free to add the term(s) into our glossary file '.spelling'." 39 | echo 40 | # set spell check as a weak check for now 41 | # FAILED=1 42 | fi 43 | 44 | echo 45 | echo "Check markdown style..." 46 | echo 47 | mdl --ignore-front-matter --style mdl_style.rb ${CHANGED_MARKDOWN_FILES[@]} 48 | if [[ "$?" != "0" ]]; then 49 | echo 50 | echo "[ERROR]: Markdown style check failed." 51 | echo 52 | FAILED=1 53 | fi 54 | else 55 | echo "No changed markdown files to check." 56 | fi 57 | } 58 | 59 | check_pull_request_content 60 | 61 | if [[ $FAILED -eq 1 ]]; then 62 | echo "LINTING FAILED" 63 | exit 1 64 | else 65 | echo "LINTING SUCCEEDED" 66 | fi 67 | -------------------------------------------------------------------------------- /scripts/mdl-check.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | FAILED=0 4 | 5 | echo -ne "mdl " 6 | mdl --version 7 | 8 | # This performs markdown style check over changed markdown files 9 | check_pull_request_content() { 10 | 11 | # only check pull request, skip others 12 | if [[ -z $CIRCLE_PULL_REQUEST ]]; then 13 | echo "Skip, only check pull request." 14 | exit 0 15 | fi 16 | 17 | # get changed files of this PR 18 | CIRCLE_PR_NUMBER=${CIRCLE_PULL_REQUEST##*/} 19 | OWNER=$(echo $CIRCLE_PULL_REQUEST | cut -d / -f 4) 20 | REPO=$(echo $CIRCLE_PULL_REQUEST | cut -d / -f 5) 21 | URL="https://api.github.com/repos/$OWNER/$REPO/pulls/$CIRCLE_PR_NUMBER/files" 22 | 23 | echo 24 | echo "Getting list of changed markdown files..." 25 | CHANGED_MARKDOWN_FILES=( $(curl -s -X GET -G $URL | jq -r '.[] | select(.status != "removed") | select(.filename | endswith(".md")) | .filename') ) 26 | echo "Total changed markdown files: ${#CHANGED_MARKDOWN_FILES[@]}" 27 | echo ${CHANGED_MARKDOWN_FILES[@]} 28 | 29 | if [[ "${#CHANGED_MARKDOWN_FILES[@]}" != "0" ]]; then 30 | mdl --ignore-front-matter --style mdl_style.rb ${CHANGED_MARKDOWN_FILES[@]} 31 | if [[ "$?" != "0" ]]; then 32 | FAILED=1 33 | fi 34 | else 35 | echo "No changed markdown files to check." 36 | fi 37 | } 38 | 39 | check_pull_request_content 40 | 41 | if [[ $FAILED -eq 1 ]]; then 42 | echo "MARKDOWN STYLE CHECK FAILED" 43 | exit 1 44 | else 45 | echo "MARKDOWN STYLE CHECK SUCCEEDED" 46 | fi 47 | -------------------------------------------------------------------------------- /scripts/mdspell-check.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | echo -ne "mdspell " 4 | mdspell --version 5 | 6 | # This performs markdown spell check over changed markdown files 7 | check_pull_request_content() { 8 | 9 | # only check pull request, skip others 10 | if [[ -z $CIRCLE_PULL_REQUEST ]]; then 11 | echo "Skip, only check pull request." 12 | exit 0 13 | fi 14 | 15 | # get changed files of this PR 16 | CIRCLE_PR_NUMBER=${CIRCLE_PULL_REQUEST##*/} 17 | OWNER=$(echo $CIRCLE_PULL_REQUEST | cut -d / -f 4) 18 | REPO=$(echo $CIRCLE_PULL_REQUEST | cut -d / -f 5) 19 | URL="https://api.github.com/repos/$OWNER/$REPO/pulls/$CIRCLE_PR_NUMBER/files" 20 | 21 | echo 22 | echo "Getting list of changed markdown files..." 23 | CHANGED_MARKDOWN_FILES=( $(curl -s -X GET -G $URL | jq -r '.[] | select(.status != "removed") | select(.filename | endswith(".md")) | .filename') ) 24 | echo "Total changed markdown files: ${#CHANGED_MARKDOWN_FILES[@]}" 25 | echo ${CHANGED_MARKDOWN_FILES[@]} 26 | 27 | if [[ "${#CHANGED_MARKDOWN_FILES[@]}" != "0" ]]; then 28 | mdspell --en-us --ignore-acronyms --ignore-numbers --no-suggestions --report ${CHANGED_MARKDOWN_FILES[@]} 29 | if [[ "$?" != "0" ]]; then 30 | echo "[WARNING]: Spell check failed. Feel free to add the term(s) into our glossary file '.spelling'." 31 | fi 32 | else 33 | echo "No changed markdown files to check." 34 | fi 35 | } 36 | 37 | check_pull_request_content 38 | --------------------------------------------------------------------------------