晴天学长
获得徽章 2
赞了这篇文章
赞了这篇文章
#青训营 x 字节后端训练营#
总结：
提到数据结构和算法的学习，一个绕不过去的问题那就是算法复杂度，包括时间复杂度分析和空间复杂度分析。
复杂度通常会使用大O记号来表示，比如冒泡排序的平均时间复杂度是O(n^2)，而快速排序的平均时间复杂度则是O(nlog(n))。
除此之外还有包括像堆、栈、队列、链表、跳表、哈希、B-Tree、堆排序、选择排序、归并排序等等一系列数据结构和算法的复杂度最好都是能要求在理解的基础上熟记的。
Big-O Cheat Sheet这个网站则把常见的数据结构和算法的各种复杂度进行了对比+整理+归纳，并制备了精美的表格，可供查阅+复习+背诵，一目了然，非常清楚。
总结：
提到数据结构和算法的学习，一个绕不过去的问题那就是算法复杂度，包括时间复杂度分析和空间复杂度分析。
复杂度通常会使用大O记号来表示，比如冒泡排序的平均时间复杂度是O(n^2)，而快速排序的平均时间复杂度则是O(nlog(n))。
除此之外还有包括像堆、栈、队列、链表、跳表、哈希、B-Tree、堆排序、选择排序、归并排序等等一系列数据结构和算法的复杂度最好都是能要求在理解的基础上熟记的。
Big-O Cheat Sheet这个网站则把常见的数据结构和算法的各种复杂度进行了对比+整理+归纳，并制备了精美的表格，可供查阅+复习+背诵，一目了然，非常清楚。
展开
评论
点赞
#青训营 x 字节后端训练营#
单纯的0和1没有任何意义，所以我们使用者会为其赋予一些特定的含义，规定解读电信号的方式：例如：多少个电信号算一组？每个信号位有何意义？这就是”数据链接层”的功能，它在”物理层”的上方，确定了物理层传输的0和1的分组方式及代表的意义。早期的时候，每家公司都有自己的电信号分组方式。逐渐地，一种叫做”以太网”（Ethernet）的协议，占据了主导地位。
以太网规定，一组电信号构成一个数据包，叫做”帧”（Frame）。每一帧分成两个部分：标头（Head）和数据（Data）。其中”标头”包含数据包的一些说明项，比如发送者、接受者、数据类型等等；”数据”则是数据包的具体内容。”标头”的长度，固定为18字节。”数据”的长度，最短为46字节，最长为1500字节。因此，整个”帧”最短为64字节，最长为1518字节。如果数据很长，就必须分割成多个帧进行发送。
那么，发送者和接受者是如何标识呢？以太网规定，连入网络的所有设备都必须具有”网卡”接口。数据包必须是从一块网卡，传送到另一块网卡。网卡的地址，就是数据包的发送地址和接收地址，这叫做MAC地址。每块网卡出厂的时候，都有一个全世界独一无二的MAC地址，长度是48个二进制位，通常用12个十六进制数表示。前6个十六进制数是厂商编号，后6个是该厂商的网卡流水号。有了MAC地址，就可以定位网卡和数据包的路径了。
单纯的0和1没有任何意义，所以我们使用者会为其赋予一些特定的含义，规定解读电信号的方式：例如：多少个电信号算一组？每个信号位有何意义？这就是”数据链接层”的功能，它在”物理层”的上方，确定了物理层传输的0和1的分组方式及代表的意义。早期的时候，每家公司都有自己的电信号分组方式。逐渐地，一种叫做”以太网”（Ethernet）的协议，占据了主导地位。
以太网规定，一组电信号构成一个数据包，叫做”帧”（Frame）。每一帧分成两个部分：标头（Head）和数据（Data）。其中”标头”包含数据包的一些说明项，比如发送者、接受者、数据类型等等；”数据”则是数据包的具体内容。”标头”的长度，固定为18字节。”数据”的长度，最短为46字节，最长为1500字节。因此，整个”帧”最短为64字节，最长为1518字节。如果数据很长，就必须分割成多个帧进行发送。
那么，发送者和接受者是如何标识呢？以太网规定，连入网络的所有设备都必须具有”网卡”接口。数据包必须是从一块网卡，传送到另一块网卡。网卡的地址，就是数据包的发送地址和接收地址，这叫做MAC地址。每块网卡出厂的时候，都有一个全世界独一无二的MAC地址，长度是48个二进制位，通常用12个十六进制数表示。前6个十六进制数是厂商编号，后6个是该厂商的网卡流水号。有了MAC地址，就可以定位网卡和数据包的路径了。
展开
评论
点赞
#青训营 x 字节后端训练营#
总结：第一种GET方法：发送一个请求来获取服务器上的某一些资源。
第二种POST方法：向URL指定的资源提交数据或附加新的数据。
第三种PUT方法：跟POST方法一样，可以向服务器提交数据，但是它们之间也所有不同，PUT指定了资源在服务器的位置，而POST没有哦。
第四种HEAD方法：指请求页面的首部。
第五种DELETE方法：删除服务器上的某资源。
第六种OPTIONS方法：它用于获取当前URL所支持的方法，如果请求成功，在Allow的头包含类似GET,POST等的信息。
第七种TARCE方法：用于激发一个远程的，应用层的请求消息回路。
第八种CONNECT方法：把请求连接转换到TCP/TP通道。
总结：第一种GET方法：发送一个请求来获取服务器上的某一些资源。
第二种POST方法：向URL指定的资源提交数据或附加新的数据。
第三种PUT方法：跟POST方法一样，可以向服务器提交数据，但是它们之间也所有不同，PUT指定了资源在服务器的位置，而POST没有哦。
第四种HEAD方法：指请求页面的首部。
第五种DELETE方法：删除服务器上的某资源。
第六种OPTIONS方法：它用于获取当前URL所支持的方法，如果请求成功，在Allow的头包含类似GET,POST等的信息。
第七种TARCE方法：用于激发一个远程的，应用层的请求消息回路。
第八种CONNECT方法：把请求连接转换到TCP/TP通道。
展开
评论
点赞
#青训营 x 字节后端训练营#
总结：
1.1.1 TCP/IP协议族
计算机与网络设备要相互通信，双方就必须要基于相同的方法。TCP/IP协议族里重要的一点就是分层。TCP/IP协议族按照层次分别分为以下4层：应用层、传输层、网络层和数据链路层。
应用层
TCP/IP协议族内预存了各类通用的应用服务。比如FTP【文件传输协议】和DNS【域名系统】就是其中两类，当然HTTP协议也在该层。
传输层
传输层对上层应用层提供处于网络连接中的两台计算机之间的数据传输。在传输层有两个性质不同的协议：TCP【Transmission Control Protocol 传输控制协议】和UDP【User Data Protocol 用户数据报协议】
网络层
网络层用于处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径到达对方计算机，并把数据包传给对方。与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线。
链路层
用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC【网络适配器俗称网卡】及光纤等物理可见部分。硬件上的范畴均在链路层的作用范围之内。
总结：
1.1.1 TCP/IP协议族
计算机与网络设备要相互通信，双方就必须要基于相同的方法。TCP/IP协议族里重要的一点就是分层。TCP/IP协议族按照层次分别分为以下4层：应用层、传输层、网络层和数据链路层。
应用层
TCP/IP协议族内预存了各类通用的应用服务。比如FTP【文件传输协议】和DNS【域名系统】就是其中两类，当然HTTP协议也在该层。
传输层
传输层对上层应用层提供处于网络连接中的两台计算机之间的数据传输。在传输层有两个性质不同的协议：TCP【Transmission Control Protocol 传输控制协议】和UDP【User Data Protocol 用户数据报协议】
网络层
网络层用于处理在网络上流动的数据包。数据包是网络传输的最小数据单位。该层规定了通过怎样的路径到达对方计算机，并把数据包传给对方。与对方计算机之间通过多台计算机或网络设备进行传输时，网络层所起的作用就是在众多的选项内选择一条传输路线。
链路层
用来处理连接网络的硬件部分。包括控制操作系统、硬件的设备驱动、NIC【网络适配器俗称网卡】及光纤等物理可见部分。硬件上的范畴均在链路层的作用范围之内。
展开
评论
点赞
升级单机处理能力的性价比越来越低
单机的处理能力主要依靠 CPU、内存、磁盘。通过更换硬件 做垂直扩展的方式来提升性能，成本会越来越高。
单机处理能力存在瓶颈
单机处理能力存在瓶颈，CPU、内存都会有自己的性能瓶颈， 也就是说就算你是土豪不惜成本去提升硬件，但是硬件的发 展速度和性能是有限制的。
稳定性和可用性这两个指标很难达到
单机系统存在可用性和稳定性的问题，这两个指标又是我们 必须要去解决的
#青训营 x 字节后端训练营#
单机的处理能力主要依靠 CPU、内存、磁盘。通过更换硬件 做垂直扩展的方式来提升性能，成本会越来越高。
单机处理能力存在瓶颈
单机处理能力存在瓶颈，CPU、内存都会有自己的性能瓶颈， 也就是说就算你是土豪不惜成本去提升硬件，但是硬件的发 展速度和性能是有限制的。
稳定性和可用性这两个指标很难达到
单机系统存在可用性和稳定性的问题，这两个指标又是我们 必须要去解决的
#青训营 x 字节后端训练营#
展开
评论
点赞
#青训营 x 字节后端训练营#
总结：
级别：⭐⭐⭐⭐
事项：项目复盘
人员：面向研发和测试人员
描述：复盘可能会因为出现事故、技术总结、分享成长，几个方向而进行的归纳、总结，避免同类事情的发生。复盘内容一般会包括技术方面的使用，例如：DB、应用开发、网关等，也包括业务领域逻辑的建设。
复盘DB：
数据库连接数配置依照业务场景申请增加
禁止使用复杂嵌套和函数类等做业务查询
防重逻辑字段加强避免造成不能防重问题
索引字段初始化检测以及慢查询问题优化
复盘业务：
对于所有营销类场景的设计需符合标准流程，缓存使用的一致性问题
资金流水结算方面在防重复设计上加强验证，测试环境模拟多样场景
对于外部支撑系统的依赖按照业务体量发展，进行通知压测报告流量
所有核心功能流程加强研发侧代码评审质量，并不断按照发展量优化
研发侧代码质量提升定期复盘问题以及优化，通过锻炼不断加强质量
在研发提测、修复、上线流程注意开发分支，避免错乱合并产生问题
所有的业务流程配置监控与图表并打印日志，方便及时追踪线上异常
核心场景的全链路压测可以有效的保证质量，也可很好降低流量风险
总结：
级别：⭐⭐⭐⭐
事项：项目复盘
人员：面向研发和测试人员
描述：复盘可能会因为出现事故、技术总结、分享成长，几个方向而进行的归纳、总结，避免同类事情的发生。复盘内容一般会包括技术方面的使用，例如：DB、应用开发、网关等，也包括业务领域逻辑的建设。
复盘DB：
数据库连接数配置依照业务场景申请增加
禁止使用复杂嵌套和函数类等做业务查询
防重逻辑字段加强避免造成不能防重问题
索引字段初始化检测以及慢查询问题优化
复盘业务：
对于所有营销类场景的设计需符合标准流程，缓存使用的一致性问题
资金流水结算方面在防重复设计上加强验证，测试环境模拟多样场景
对于外部支撑系统的依赖按照业务体量发展，进行通知压测报告流量
所有核心功能流程加强研发侧代码评审质量，并不断按照发展量优化
研发侧代码质量提升定期复盘问题以及优化，通过锻炼不断加强质量
在研发提测、修复、上线流程注意开发分支，避免错乱合并产生问题
所有的业务流程配置监控与图表并打印日志，方便及时追踪线上异常
核心场景的全链路压测可以有效的保证质量，也可很好降低流量风险
展开
评论
点赞
#青训营 x 字节后端训练营#
总结：腾讯微服务平台（Tencent Service Framework，TSF）是一个围绕着应用和微服务的PaaS技术平台，提供应用全生命周期管理、数据化运营、立体化监控和服务治理等功能。TSF拥抱Spring Cloud、Service Mesh微服务框架，帮助企业客户解决传统集中式架构转型的困难，打造大规模高可用的分布式系统架构，实现业务、产品的快速落地。TSF以腾讯云中间件团队多款成熟的分布式产品为核心基础组件，提供秒级推送的分布式配置服务、链路追踪等高可用稳定性组件。此外，TSF与腾讯云API网关和消息队列打通，让企业轻松构建大型分布式系统。
在TSF的微服务架构体系中，服务总数并不多，大概40+左右，就数量而言TSF本身的架构规模属于偏中小型的微服务架构。这是因为，TSF产品本质上是一整套业务支撑技术平台，其微服务架构表面看显得十分精巧，相比大型系统架构为了应对高并发、海量存储等因素而产生的架构复杂性，TSF架构设计的权衡与内涵思考则主要体现在产品的稳定、内聚、高可用等方面。
总结：腾讯微服务平台（Tencent Service Framework，TSF）是一个围绕着应用和微服务的PaaS技术平台，提供应用全生命周期管理、数据化运营、立体化监控和服务治理等功能。TSF拥抱Spring Cloud、Service Mesh微服务框架，帮助企业客户解决传统集中式架构转型的困难，打造大规模高可用的分布式系统架构，实现业务、产品的快速落地。TSF以腾讯云中间件团队多款成熟的分布式产品为核心基础组件，提供秒级推送的分布式配置服务、链路追踪等高可用稳定性组件。此外，TSF与腾讯云API网关和消息队列打通，让企业轻松构建大型分布式系统。
在TSF的微服务架构体系中，服务总数并不多，大概40+左右，就数量而言TSF本身的架构规模属于偏中小型的微服务架构。这是因为，TSF产品本质上是一整套业务支撑技术平台，其微服务架构表面看显得十分精巧，相比大型系统架构为了应对高并发、海量存储等因素而产生的架构复杂性，TSF架构设计的权衡与内涵思考则主要体现在产品的稳定、内聚、高可用等方面。
展开
评论
点赞
#青训营 x 字节后端训练营#
1.5 无处安放的业务逻辑
关于业务逻辑其实是一个很笼统的概念，甚至可以将任意一行代码称之为业务逻辑，如此宽泛的概念我们该如何去理解？我先大致将它分为两个方面：
界面交互逻辑：视图层的交互逻辑，比如手势控制、吸顶悬浮等等都是根据业务需要实现的，所以严格来说这部分也属于业务逻辑。但这部分业务逻辑一般在视图层实现。
数据逻辑：这部分是大家常说的业务逻辑，属于强业务逻辑，比如根据不同用户类型获取不同数据、展示不同界面，加上Data Mapper一系列操作其实就是给后端兜底，帮他们补全剩余逻辑而已。为了方便大家理解下文我将数据逻辑统称为业务逻辑。
前面我们说到，Android开发应该具备数据层跟视图层，那业务逻辑放在哪一层比较合适呢？比如MVVM模式下大家都说将业务逻辑放到ViewModel处理，这么说也没有太大的问题，但如果一个界面足够复杂那对应的ViewModel代码可能会有成百上千行，看起来会很臃肿可读性也非常差。最重要的一点这些业务很难编写单元测试用例。
关于业务逻辑我建议单独写一个use case处理。
use case通常放在ViewModel/Presenter与数据层之间，业务逻辑以及Data Mapper都应该放在use case中，每一个行为对应一个use case。这样就解决了ViewModel/Presenter臃肿的问题，同时更方便编写测试用例。
注意点：
好的设计都是特定场景解决特定问题，过度设计不仅解决不了任何问题反而会增加开发成本。以我目前经验来看Android开发至少一半的场景都很简单：请求-->拿数据-->渲染视图最多再加个Data Mapper，流程很单一并且后期改动的可能也不太大，这种情况就没必要写一个use case，Data Mapper扔到数据层即可。
1.5 无处安放的业务逻辑
关于业务逻辑其实是一个很笼统的概念，甚至可以将任意一行代码称之为业务逻辑，如此宽泛的概念我们该如何去理解？我先大致将它分为两个方面：
界面交互逻辑：视图层的交互逻辑，比如手势控制、吸顶悬浮等等都是根据业务需要实现的，所以严格来说这部分也属于业务逻辑。但这部分业务逻辑一般在视图层实现。
数据逻辑：这部分是大家常说的业务逻辑，属于强业务逻辑，比如根据不同用户类型获取不同数据、展示不同界面，加上Data Mapper一系列操作其实就是给后端兜底，帮他们补全剩余逻辑而已。为了方便大家理解下文我将数据逻辑统称为业务逻辑。
前面我们说到，Android开发应该具备数据层跟视图层，那业务逻辑放在哪一层比较合适呢？比如MVVM模式下大家都说将业务逻辑放到ViewModel处理，这么说也没有太大的问题，但如果一个界面足够复杂那对应的ViewModel代码可能会有成百上千行，看起来会很臃肿可读性也非常差。最重要的一点这些业务很难编写单元测试用例。
关于业务逻辑我建议单独写一个use case处理。
use case通常放在ViewModel/Presenter与数据层之间，业务逻辑以及Data Mapper都应该放在use case中，每一个行为对应一个use case。这样就解决了ViewModel/Presenter臃肿的问题，同时更方便编写测试用例。
注意点：
好的设计都是特定场景解决特定问题，过度设计不仅解决不了任何问题反而会增加开发成本。以我目前经验来看Android开发至少一半的场景都很简单：请求-->拿数据-->渲染视图最多再加个Data Mapper，流程很单一并且后期改动的可能也不太大，这种情况就没必要写一个use case，Data Mapper扔到数据层即可。
展开
评论
点赞