这是我参与「第三届青训营 -后端场」笔记创作活动的的第一篇笔记.

本次青训营课程中，微服务架构课程分为上下两篇，这是上篇《架构初探-谁动了我的蛋糕》。后续相关课程有《微服务架构原理与治理实践》。
我把《架构初探-谁动了我的蛋糕》的笔记也分为上下两篇。这是上篇，主要简单介绍了一下架构的基本知识，以及对企业级后端架构进行了刨析。
(架构初探-谁动了我的蛋糕 (下篇)| 青训营笔记 - 掘金 (juejin.cn))

话不多说，我们开启本篇笔记~

1.什么是架构

架构，又称软件架构，

是有关软件整体结构与组件的抽象描述
用于指导软件系统各个方面的设计

我个人的理解就是房子的地基，字节跳动这些年迅猛发展的原因也得益于优秀的鸡架团队。

单机架构

软件系统需要具备对外提供服务，单机，就是把所有功能都实现在一个进程里，并部署在一台机器上

优点：简单

缺点：运维需要停服

个人理解：把所有东西都部署到一台机器上的话，那台机器挂了，那么整个服务都宕机了！非常危险，所以这种单机架构不适合大企业运用。故业界普遍流行的是HA高可用集群~运用Zookeeper

单体架构,垂直应用|垂直切分

单体架构：分布式部署,就是把单机架构部署都熬部署到多个架构
垂直应用架构：按应用垂直切分的单体
优点：水平扩容，不需要停服运维
缺点：职责多带来的开发效率不够高，爆炸半径大

SOA，微服务|水平切分

SOA(Service-o riented Architecture)

将应用的不同功能单元抽象为服务
定义服务之间的通信标准
优点：耦合度低，各个服务互不干扰
缺点：服务间通讯需要团队协调，测试更加困难了 微服务架构：SOA的去中心化演进方向

第一部分总结

架构演进的初衷：需求量越来越大，需要增加人手进而需要分工合作
架构演进的思路：垂直切分——分布式(单体架构)，水平切分——微服务(SOA)

2.企业级后端架构刨析

云计算:是指通过软件自动化管理，提供计算资源的服务网络，是现代互联网大规模熟悉分析和存储的基石。

基础:

虚拟化技术
编排方案

架构：

laaS(Infrastructure as a Server):基础设施即服务，服务商提供底层基础设施资源（服务器，数据中心，环境控制，电源，服务器机房），客户自己部署和执行操作系统或应用程序等各种软件。
PaaS(Platform as a Server):平台即服务，服务商提供基础设施底层服务，提供操作系统（Windows，Linux）、数据库服务器、Web服务器、域控制器和其他中间件，以及服务模型中的备份服务等中件层服务。
SaaS(Software as a Server):软件即服务，服务商提供基于软件的解决方案，满足客户最终需求；如Office 365、iCloud。
FaaS(Function as a Server):函数即服务，服务商提供一个平台，允许客户开发、运行和管理应用程序功能，而无需构建和维护通常与开发和启动应用程序相关的基础架构的复杂性。按照此模型构建应用程序是实现“无服务器”体系结构的一种方式，通常在构建微服务应用程序时使用。国内的云服务器商如阿里云、腾讯云都有云函数功能。

云原生:为组织(公司)在公有云、自由云、混合云等新型的动态环境中，构建和运行可弹性拓展的应用提供了可能。

个人理解Golang近些年发展得这么好，主要也是因为目前是云原生时代和容器时代。Golang精准的踩在了这两个大节奏下面。

云原生(Cloud Naive)主要代表应用有:

弹性资源：虚拟化容器/快速扩缩容
微服务架构：业务功能单元解耦/统一的通信标准
DevOps：敏捷开发(字节内部也是采取这种方式)/ CI(持续集成)/CD(持续交付)
服务网格：业务与治理解构/异构系统的治理统一化/复杂治理能力

弹性计算资源:

1.服务资源调度：

微服务：和面，雕花
大服务：烤箱

2.计算资源调度：

在线：热销榜单
离线：热销榜单更新

3.消息队列(MQ)：

在线：削峰、解耦
离线：大数据分析

弹性存储资源类型:

经典存储
- 对象:存储图片视频等文件，为APP提供丰富的多媒体资源
- 大数据存储 - 比如用户消费记录，可以用于生成用户画像
关系型数据库
- 收银记录
元数据
- 服务发现
NoSQL
- KV 存储 - Redis
- 文档存储 - Mongo

DevOps:

DevOps是云原生时代软件交付的利器，贯穿整个软件开发周期。后续会有一篇文章《从需求到上线全流程》进行介绍。

微服务架构:

通信标准：

HTTP(RESTful API)
RPC(Thrift,gRPC)

微服务中间件RPC VS HTTP：

性能：
- RPC：使用自定义的TCP协议，可以让请求报文体积更小，或者选用HTTP/2协议，两种方案的效率都比传统HTTP高。
- HTTP：如果选取基于HTTP/1.1的协议请求报文中会多许多无用的内容，选用HTTP2也可以封装成一个RPC进行使用，相对于标准的RPC框架少了服务治理。
服务治理：
- RPC集成了熔断、降级、超时等机制，以及自带了负载均衡策略。
协议可解释性：
- RPC：可以基于Thrift实现高效的二进制传输HTTP
- HTTP：主要通过JSON实现，也可以用如XML等进行实现，字节大小和序列化耗时都比Thrift更耗费性能

服务网格:

服务网格(Service Mesh)：

微服务之间通讯的中间层
高性能网络代理
治理与业务解耦

相比较于 RPC/HTTP 框架：

异构系统治理的统一化
与业务进程解耦，生命周期也更容易管理

架构初探-谁动了我的蛋糕 (上篇)| 青训营笔记