晴天学长
获得徽章 2
#青训营 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扔到数据层即可。
展开
评论
点赞
#青训营 x 字节后端训练营#
总结：
具体实施
1）接口文档服务器：可实现接口变更实时同步给前端展示；
2）Mock接口数据平台：可实现接口变更实时Mock数据给前端使用；
3）接口规范定义：很重要，接口定义的好坏直接影响到前端的工作量和实现逻辑；
规范原则
1）接口返回数据即显示：前端仅做渲染逻辑处理；
2）渲染逻辑禁止跨多个接口调用；
3）前端关注交互、渲染逻辑，尽量避免业务逻辑处理的出现；
4）请求响应传输数据格式：JSON，JSON数据尽量简单轻量，避免多级JSON的出现；
总结：
具体实施
1）接口文档服务器：可实现接口变更实时同步给前端展示；
2）Mock接口数据平台：可实现接口变更实时Mock数据给前端使用；
3）接口规范定义：很重要，接口定义的好坏直接影响到前端的工作量和实现逻辑；
规范原则
1）接口返回数据即显示：前端仅做渲染逻辑处理；
2）渲染逻辑禁止跨多个接口调用；
3）前端关注交互、渲染逻辑，尽量避免业务逻辑处理的出现；
4）请求响应传输数据格式：JSON，JSON数据尽量简单轻量，避免多级JSON的出现；
展开
评论
点赞
#青训营 x 字节后端训练营#
总结：
HTTP 特点
HTTP 的特点概括如下:
灵活可扩展，主要体现在两个方面。一个是语义上的自由，只规定了基本格式，比如空格分隔单词，换行分隔字段，其他的各个部分都没有严格的语法限制。另一个是传输形式的多样性，不仅仅可以传输文本，还能传输图片、视频等任意数据，非常方便。
可靠传输。HTTP 基于 TCP/IP，因此把这一特性继承了下来。这属于 TCP 的特性，不具体介绍了。
请求-应答。也就是一发一收、有来有回， 当然这个请求方和应答方不单单指客户端和服务器之间，如果某台服务器作为代理来连接后端的服务端，那么这台服务器也会扮演请求方的角色。
无状态。这里的状态是指通信过程的上下文信息，而每次 http 请求都是独立、无关的，默认不需要保留状态信息。
总结：
HTTP 特点
HTTP 的特点概括如下:
灵活可扩展，主要体现在两个方面。一个是语义上的自由，只规定了基本格式，比如空格分隔单词，换行分隔字段，其他的各个部分都没有严格的语法限制。另一个是传输形式的多样性，不仅仅可以传输文本，还能传输图片、视频等任意数据，非常方便。
可靠传输。HTTP 基于 TCP/IP，因此把这一特性继承了下来。这属于 TCP 的特性，不具体介绍了。
请求-应答。也就是一发一收、有来有回， 当然这个请求方和应答方不单单指客户端和服务器之间，如果某台服务器作为代理来连接后端的服务端，那么这台服务器也会扮演请求方的角色。
无状态。这里的状态是指通信过程的上下文信息，而每次 http 请求都是独立、无关的，默认不需要保留状态信息。
展开
评论
点赞
#青训营 x 字节后端训练营#
总结：
kafka是目前最常用的消息队列，尤其是在大数据方面，有着极高的吞吐量。而rocketmq和rabbitmq，都是电信级别的消息队列，在业务上用的比较多。相比较而言，ActiveMQ使用的最少，属于较老一代的消息框架。
pulsar是为了解决一些kafka上的问题而诞生的消息系统，比较年轻，工具链有限。有些激进的团队经过试用，反响不错，但实际使用并不多。
mqtt具体来说是一种协议，主要用在物联网方面，能够双向通信，属于消息队列范畴，推荐使用vernemq。
总结：
kafka是目前最常用的消息队列，尤其是在大数据方面，有着极高的吞吐量。而rocketmq和rabbitmq，都是电信级别的消息队列，在业务上用的比较多。相比较而言，ActiveMQ使用的最少，属于较老一代的消息框架。
pulsar是为了解决一些kafka上的问题而诞生的消息系统，比较年轻，工具链有限。有些激进的团队经过试用，反响不错，但实际使用并不多。
mqtt具体来说是一种协议，主要用在物联网方面，能够双向通信，属于消息队列范畴，推荐使用vernemq。
展开
评论
点赞
#青训营 x 字节后端训练营#
总结：
TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。
总结：
TiDB 是 PingCAP 公司自主设计、研发的开源分布式关系型数据库，是一款同时支持在线事务处理与在线分析处理 (Hybrid Transactional and Analytical Processing, HTAP）的融合型分布式数据库产品，具备水平扩容或者缩容、金融级高可用、实时 HTAP、云原生的分布式数据库、兼容 MySQL 5.7 协议和 MySQL 生态等重要特性。目标是为用户提供一站式 OLTP (Online Transactional Processing)、OLAP (Online Analytical Processing)、HTAP 解决方案。TiDB 适合高可用、强一致要求较高、数据规模较大等各种应用场景。
展开
评论
点赞
#青训营 x 字节后端训练营#
总结：
1.4.1 Go入门指南 比较适合新手，内容相对基础一些
1.4.2 Go语言圣经 书如其名
1.4.3 Go语言中文网 找对圈子，学的更快
1.4.4 菜鸟教程 这个网站非常适合快速上手某门语言
1.4.5 Go语言高级编程 内容适合进阶
1.4.6 go语言原本 欧神出品，虽然号称进度只有9.9%/100%，但不妨碍它的优秀，值得一看
1.4.7 golang设计模式 设计模式 Golang实现，《研磨设计模式》的golang实现
1.4.8 Go实战开发 作者是著名的 Go 开源项目 beego 的作者，他的最佳实践非常值得阅读
1.4.9 Go palyground 不用搭建本地 Go 环境，在线就编写 Go 的代码
总结：
1.4.1 Go入门指南 比较适合新手，内容相对基础一些
1.4.2 Go语言圣经 书如其名
1.4.3 Go语言中文网 找对圈子，学的更快
1.4.4 菜鸟教程 这个网站非常适合快速上手某门语言
1.4.5 Go语言高级编程 内容适合进阶
1.4.6 go语言原本 欧神出品，虽然号称进度只有9.9%/100%，但不妨碍它的优秀，值得一看
1.4.7 golang设计模式 设计模式 Golang实现，《研磨设计模式》的golang实现
1.4.8 Go实战开发 作者是著名的 Go 开源项目 beego 的作者，他的最佳实践非常值得阅读
1.4.9 Go palyground 不用搭建本地 Go 环境，在线就编写 Go 的代码
展开
评论
点赞
#青训营 x 字节后端训练营#
总结：fasthttp号称比net/http快十倍，其优化的核心思路很简单：资源复用。
复用 goroutine，减轻 runtime 调度压力；
对象复用，大量使用 sync.Pool 减轻 GC 压力。
除了复用，还有其他的一些优化手段，例如尽量避免 string 与 []byte 的转换开销等。
这些优化技巧和最佳实践，在其 Github 主页上已经贴心给出：_github.com/valyala/fas…
因为fasthttp的实现与标准库差距较大，所以它与net/http的 API 接口是不同的，这导致从net/http重构为fasthttp需要一些学习成本。
使用fasthttp的知名项目：Fiber、Gearbox、atreugo 等。
总结：fasthttp号称比net/http快十倍，其优化的核心思路很简单：资源复用。
复用 goroutine，减轻 runtime 调度压力；
对象复用，大量使用 sync.Pool 减轻 GC 压力。
除了复用，还有其他的一些优化手段，例如尽量避免 string 与 []byte 的转换开销等。
这些优化技巧和最佳实践，在其 Github 主页上已经贴心给出：_github.com/valyala/fas…
因为fasthttp的实现与标准库差距较大，所以它与net/http的 API 接口是不同的，这导致从net/http重构为fasthttp需要一些学习成本。
使用fasthttp的知名项目：Fiber、Gearbox、atreugo 等。
展开
评论
点赞
2月23日 打卡day8
今日学习
Bytebase是一款面向开发者的数据库变更管理工具，目前在Github上已有3.6K+Star。
它的主要特性如下：
SQL审核：具有一站式SQL审核面板，可以直观地看到数据库所有变更记录。
SQL建议：能自动检查SQL语句规范，额外提供GitHub Action和API接入方式。
SQL编辑器：可以在线管理及查看数据库表，支持语法的自动提示。
GitOps工作流：支持集成GitHub和GitLab，使用GitOps工作流进行数据库变更。
备份恢复：支持自动备份数据库及恢复数据。
今日学习
Bytebase是一款面向开发者的数据库变更管理工具，目前在Github上已有3.6K+Star。
它的主要特性如下：
SQL审核：具有一站式SQL审核面板，可以直观地看到数据库所有变更记录。
SQL建议：能自动检查SQL语句规范，额外提供GitHub Action和API接入方式。
SQL编辑器：可以在线管理及查看数据库表，支持语法的自动提示。
GitOps工作流：支持集成GitHub和GitLab，使用GitOps工作流进行数据库变更。
备份恢复：支持自动备份数据库及恢复数据。
展开
评论
点赞
2月20日 打卡day7
今日学习
连接层：主要是指数据库连接池，会负责处理所有客户端接入的工作。
服务层：主要包含SQL接口、解析器、优化器以及缓存缓冲区四块区域。
存储引擎层：这里是指MySQL支持的各大存储引擎，如InnoDB、MyISAM等。
文件系统层：涵盖了所有的日志，以及数据、索引文件，位于系统硬盘上。
今日学习
连接层：主要是指数据库连接池，会负责处理所有客户端接入的工作。
服务层：主要包含SQL接口、解析器、优化器以及缓存缓冲区四块区域。
存储引擎层：这里是指MySQL支持的各大存储引擎，如InnoDB、MyISAM等。
文件系统层：涵盖了所有的日志，以及数据、索引文件，位于系统硬盘上。
展开
评论
点赞
2月10日 打卡day6
今日学习
Kafka 和传统的消息系统(也称作消息中间件)都具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。与此同时，Kafka 还提供了大多数消息系统难以实现的消息顺序性保障及回溯消费的功能。
今日学习
Kafka 和传统的消息系统(也称作消息中间件)都具备系统解耦、冗余存储、流量削峰、缓冲、异步通信、扩展性、可恢复性等功能。与此同时，Kafka 还提供了大多数消息系统难以实现的消息顺序性保障及回溯消费的功能。
评论
1
#青训营笔记创作活动#
2月9日 打卡day5
今日学习
如果查询条件是sname = "变成派大星" and s_code = 2或者a=1(又或者是s_code = 2 and sname = "变成派大星" )就可以，因为优化器会自动调整sname, s_code的顺序。再比如sname = "变成派大星" and s_code > 1 and address = "上海" address是用不到索引的，因为s_code字段是一个范围查询，它之后的字段会停止匹配 ----- 为啥那个优化器会不会自动调整sname = "变成派大星" and address = "上海" and s_code > 1
2月9日 打卡day5
今日学习
如果查询条件是sname = "变成派大星" and s_code = 2或者a=1(又或者是s_code = 2 and sname = "变成派大星" )就可以，因为优化器会自动调整sname, s_code的顺序。再比如sname = "变成派大星" and s_code > 1 and address = "上海" address是用不到索引的，因为s_code字段是一个范围查询，它之后的字段会停止匹配 ----- 为啥那个优化器会不会自动调整sname = "变成派大星" and address = "上海" and s_code > 1
展开
评论
点赞