---
title: "持续演进的Cloud Native (读书笔记05)"
description: "未来值得关注的方向Serverless无服务器架构是基于互联网的系统，它的应用开发不使用常规的服务进程。相"
date: 2020-03-10T16:00:00Z
canonical: https://xiaobox.github.io/p/2020-03-10-chi-xu-yan-jin-de-cloud-native-du-shu-bi-ji-05/
author: 小盒子
categories: ["云原生"]
tags: ["Java", "Kubernetes", "Istio", "Git", "架构", "多线程", "DevOps"]
source: https://mp.weixin.qq.com/s/8pLyiBY08HfOwsqKtX0nRQ
license: CC BY-NC-SA 4.0
license_url: https://creativecommons.org/licenses/by-nc-sa/4.0/
---

# 持续演进的Cloud Native (读书笔记05)

**未来值得关注的方向**

-   Serverless

-   无服务器架构是基于互联网的系统，它的应用开发不使用常规的服务进程。相反，它仅依赖于第三方服务（例如 AWS Lambda 服务），是客户端逻辑和服务托管远程过程调用的组合

-   什么是Serverless

-    Service Mesh

-   Service Mesh是用于处理服务到服务通信的专用基础架构层。Cloud Native有着复杂的服务拓扑，它负责可靠地传递请求。实际上，Service Mesh 通常作为一组轻量级网络代理实现，这些代理与应用程序代码部署在一起，应用程序无感知。随着Cloud Native的崛起，Service Mesh逐步发展为一个独立的基础设施层。在Cloud Native架构下，单个应用程序可能由数百个服务组成；每个服务可能有数千个实例；并且这些实例中的每一个实例都可能处于不断变化的状态，因为它们是由诸如Kubernetes之类的资源调度系统动态调度的。这个世界中的服务通信不仅非常复杂，而且是运行时行为的普遍和基本部分，管理它对于确保端到端的性能和可靠性至关重要。

-   什么是Service Mesh

 **研发流程**

-   十二因子

-   基准代码

-   一份基准代码，多份部署

-   使用 GIT 或者 SVN 管理代码，并且有明确的版本信息

-   依赖

-   显式声明依赖关系。

-   如Java中我们可以使用Maven或者Gradle管理依赖包

-   配置

-   在环境中存储配置

-   第一，可以将应用的配置存储于环境变量中；第二，可以将应用的配置存储于分布式配置中心。

-   后端服务

-   把后端服务当作附加资源

-   构建、发布、运行

-   严格分离构建和运行

-   十二因子强调通过CI/CD（持续集成/持续布置）工具实现整个过程，例如使用Jenkins。

-   进程

-   以一个或多个无状态进程运行应用

-   端口绑定

-   通过端口绑定提供服务

-   并发

-   通过进程模型进行扩展

-   易处理

-   快速启动和优雅终止可最大化健壮性

-   开发环境与线上环境等价

-   尽可能保持开发、预发布、线上环境相同

-   日志

-   把日志当作事件流

-   管理进程

-   把后台管理任务当作一次性进程运行

-   Code Review的意义

-   Code Review，顾名思义，就是针对一名开发人员完成的代码，让团队其他开发人员检查的过程。很多公司都在开展 Code Review，但是绝大多数公司只是流于形式，并没有形成一种文化。Code Review更多依靠的是小团队的工匠精神和程序员个人的主观能动性

-   Code Review的原则

-   以发现问题为目标

-   不设置惩罚 而应该采用正向激励的做法

-   不论资历

-   Code Review的过程

-   利用工具 线上+线下结合

-    代码即设计

-   架构设计包含两方面，一是架构，二是设计。在敏捷开发中，架构并没有被抛弃，架构的思考可能发生在你理解需求的过程中，也可能来自你的经验；架构的结果可能是一个白板上简单的图，也可能需要详细调研，这与架构师的能力有关。设计需要耗费大量的时间和精力去做，设计会转移、分配到整个研发流程。

-   整个进化设计需要简单的架构+持续集成+重构+整个研发流程的设计来保证。

-   敏捷研发流程模糊阶段性的理由是：业务需求太多和技术变化速度太快。

-   这种设计上的转变实际上非常适合小规模、有强大战斗力的团队

 **团队文化**

-   高效的会议

-   缩小会议范围

-   常规会议不应该超过45分钟

-   限制“意见领袖”的发言时长

-   提供平等的会议氛围

-   会议中的分歧不应该延伸到会议之外

-    如何留下你想要的人

-   充分沟通

-   给予尊重

-   肯定工作成绩

-   设定合适的岗位

-   设定更大的挑战

![Image](https://pub-f29bf2b53160470c9a85250116509a24.r2.dev/post/2020-03-10-chi-xu-yan-jin-de-cloud-native-du-shu-bi-ji-05/001-bf98d7fd.jpg)

关注公众号 获取更多精彩内容