班会第 52 期

Question

班会第 52 期

ufologist opened this issue 8 years ago · 0 comments

ufologist commented 8 years ago

技术
- 从css谈模块化
  - 前端的工作内容主要涉及三个方面：html、css、js（javascript）
  - 那我们所说的模块化也可以分别当成这三条线去看，如html的模块化、css的模块化，以及js的模块化，这三者我们称为（web）前端模块化
  - 我们这里所谓的模块化，其实是规范化的子集，通过制定了一套规范，才产生了模块。所以css的模块化过程其实是css规范化的过程
  事实上我们手打css遇到的问题可以大致归纳为以下几, 往往要依赖“规范”来解决
  - 选择器繁琐冗长
  - 命名冲突
  - 层级结构不清晰
  - 代码难以复用
  要实现代码复用很简单，我们只需要提供一个公共css库(common.css)，来存放我们的公共样式以及公共模块即可
  - common的体积膨胀
  - 对于只需要用到少量公共样式的页面, common很“重”
  - common 与独立页面样式之间的冲突
  网易的NEC是其中一种比较完整的解决方案, 我们规定页面由且只由几种基本结构体构成：框架(.g-)、模块(.m-)，以及元件(.u-)
  
  一个css模块应该遵循以下几点要求
  - 只对外暴露一个类名
  - 不影响周围布局: 一般情况下，尽量不要使用一个脱离文档流的布局，尽量不要使用外边距. 这是为了使得模块更加稳定、具备更高的可塑性
  - 模块尽量设计为方便复用的量级，避免大而全，求精巧
  - 后续添加公共模块可能与其他页面的私有模块命名冲突
  - 根本原因在于，我们无法事先规划好所有的模块，无法在一开始就对一个模块的属性清晰地划分
  - 这个问题也基本算是无解。矛盾在于，我们对模块进行了私有和公有的属性划分，却无法事先掌握所有的模块属性，只能走一步算一步，错了就回来再改改
```
<!DOCTYPE html>
<html>
<head>
  <title>index</title>
</head>
<body>
  <div class="g-index">
    <div class="g-hd">
      <img class="u-logo" alt="logo">
      <div class="m-nav">
        nav
        <a href="/logoin" class="u-login_btn">登录</a>
      </div>
    </div>
    <div class="g-bd">
      <div class="m-news">news</div>
    </div>
    <div class="g-ft">
      <div class="m-copy_right">copy_right</div>
    </div>
  </div>
</body>
</html>
```
- css预处理语言的模块化实践
  .scss
  - 选择器的嵌套（nesting）
  - 变量（$variable）
  - 混合（@mixin/@include）在需要使用到的地方，直接引用（include），而在引用之前，这段代码都不会出现在编译后的文件中，也就是不会生成任何内容
  - @import
  - 函数（@function/@return）
  通过 sass 模块化的途径主要是依靠 @mixin 机制来定义模块, 其他地方按需 @include 使用模块
```
// common.scss
@import './reset.scss';         // normalize
@import './bootstrap.min.scss'; // 插件, scss是兼容原生css语法的, 改一下扩展名为.scss就可以了
@import './mixin.scss';         // mixin(全局变量/模块定义)
```
```
// index.scss
@import './mixin';

.g-index {
  ...
}
```
```
<link rel="stylesheet" href="common.css">
<link rel="stylesheet" href="index.css">
```
  BEM Mixins
```
// Block Element
// @access public
// @param {String} $element - Element's name
@mixin element($element) {
    &__#{$element} {
        @content;
    }
}

// Block Modifier
// @access public
// @param {String} $modifier - Modifier's name
@mixin modifier($modifier) {
    &--#{$modifier} {
        @content;
    }
}

.block {
    /* CSS declarations for `.block` */

    @include element('element') {
        /* CSS declarations for `.block__element` */
    }

    @include modifier('modifier') {
        /* CSS declarations for `.block--modifier` */

        @include element('element') {
            /* CSS declarations for `.block--modifier__element` */
        }
    }
}
```
- 项目架构设计总结
  基于阿里云搭建适合项目初期的后端轻量级架构
  
  项目后端架构使用阿里云服务搭建，其中RDS为主从集群，并配备灾备实例。ECS可根据业务量动态弹性伸缩，其余服务均采用单实例的方式远程调用。
  - VPC
    - 可以将业务数据库和业务服务器放置在可以自己掌握的同一内网，可以提高一些安全性。
    - 阿里云服务之间通过内网访问的流量是不收费的。所以在选购服务时，带宽可以选择流量版，这样在保证带宽速率的同时，还可以极大的减少运维费用。
    - ECS仅处理业务逻辑，几乎不存储文件资源。大部分静态资源，如视频图片等，都是存储在OSS上。如果存放静态资源，比如下视频或图片什么的，流量一多那就很亏了
    - 内网访问，稳定而且速度快
  - 业务数据层
    - RDS: 项目一开始，RDS选购的是共享型单实例的，随着业务量的提升，可以多区域部署只读实例。另外，保险起见，主实例可以配有一个灾备实例，防止意外发生。
    - Redis: 做数据缓存，响应速度非常快。因为是放置在内网的且只能内网访问，所以安全性也很高。
    - MongoDB: 结构型数据，主要存储档案式的数据，比如每个用户的操作行为，以档案式记录并进行统计分析，方便下一阶段的项目做个性化服务。另外一些关联复杂的数据，也可以用MongoDb存储，可以提高访问速度。还有，一些对软件应用版本比较敏感的数据也可以存在MongoDB中
  - 静态资源
    - OSS + CDN: OSS存储静态资源，CDN(内容分发网络)可以加速静态资源的下载速度。至于资源链接地址，客户端可以通过接口访问从后端业务数据库中拿到
  - 服务器安全
    - 运维层面: web防火墙和态势感知的服务, 配置firewalld
    - 业务层面: 签名验证, 访问频次限制, https, 敏感数据使用RSA非对称加密
  - 服务器集群
    - 主ECS: 通过这台ECS，可以管理其它从属的ECS，并查看状态。安装的主要工具为ansible
    - 从属ECS: 只存放逻辑代码，所以当需求量增加时，只需增加此类服务器的个数即可. 在增加个数时，可以使用之前制作好的镜像，创建多台相同环境的ECS服务器，微服务容器环境用的docker
    - 负载均衡: 负载均衡实例(注意要买带公网ip的)。由该负载均衡实例接收请求后，会分发到内部服务器(管理起来比较方便，节省人力). 或者在某台具有外网ip的ECS上使用nginx部署负载均衡服务
  - 使用到的第三方服务
    - Coding: 私有git仓库没有个数限制, 后端代码的自动部署是通过Coding的webhook实现的
    - 容联·云通讯: 短信通知、验证码
    - 融云IM: 客户端之间的即时通讯以及客户端的应用消息推送
  根据业务量提高性能
  - http请求的并发性能可以通过增加ECS实现
  - 数据库的并发连接数可以通过增加配置来提高，也可以通过创建只读实例进行读写分离，提高数据处理能力
- 做一个 App 前需要考虑的几件事
  做一个 App 的成本越来越低了，但有些事情最好前期就做起来，避免当 App 有了一定规模后，再感慨当初为什么没有多留点心。
  - 完善的日志系统
  - Commit Message 规范
  - 代码规范
  - 准备一份编程守则
    - 里面包含了「最佳实践」和「不要踩的坑」，这个可以一定程度上提高开发效率，避免一些低级错误
  - 页面布局规范
  - 统计埋点
  - App 架构
    - 大方向上也就是 MVP / MVVM，等人员多起来时，基本就是组件化开发
  - 页面跳转机制
  - 在线配置
  - Crash 平台
  - Code Review
  - 开发模式
  - 持续集成
  - Bug 管理系统
  - 项目管理工具
  - Checklist
- App Store 狠抓精神文明建设，JSPatch要亡了？
  事情的主要起因在 App Store Review Guide Line 的 2.5.2 这条：这条是在16年WWDC之后更新上去的。这条规则也很容易理解，所有被执行的代码都应该包含在App里，不能下载代码到本地执行。下发的无论是OC还是JS或者其他形式的代码，都可以被认为违反了这条规则。但是苹果一直没有严格“执法”，直到今天才开始给大批有类似嫌疑的开发者发了警告邮件，或者纷纷被拒。
  
  根据看到的反馈，目前苹果判断的依据主要有两条
  - 扫描特定的 API: 但是这里并不是完全禁止使用这些 API ，只是有个规则会检查这些 API 的参数是不是可能是外部引入的
  - 检查特定的类名: 比如大家都知道的JSPatch和Rollout，发现APP里带了这样有潜在威胁的库就可能打回。但是这个方式似乎通过混淆就能过关
  对未来的判断
  - 苹果是百分百不愿意代码绕过审核被下发的
  - 聪明的人已经在如何提APP稳定性的道路上努力了。忘了HotPatch这件事吧。发代码这件事是不是真的影响到App运行非做不可？如果代价提高呢？比如被发现一次直接封掉你的Apple ID，觉得还是非做不可？
  关于苹果警告 | JSPatch 的作者
  - 苹果为什么这么做呢？
    - 可控和安全
    - 开发方式/滥用
- Nuxt.js @px0078
  2016 年 10 月 25 日，zeit.co 背后的团队对外发布了 Next.js，一个 React 的服务端渲染应用框架。几小时后，与 Next.js 异曲同工，一个基于 Vue.js 的服务端渲染应用框架应运而生，我们称之为：Nuxt.js。
  - Nuxt.js 预设了利用Vue.js开发服务端渲染的应用所需要的各种配置
  - 我们还提供了一种命令叫：nuxt generate，为基于 Vue.js 的应用提供生成对应的静态站点的功能
- 视频直播的技术原理和实现思路方案整理
  包括原理篇/思路篇/实践篇/方案篇/前端篇/总结
  - 如果想最快的实现直播功能, 最好选用直播云, 因为其提供了完善的 SDK, 从推流到流服务器再到最终的播放器, 一条龙服务下来.
  - 如果想自己搭建整个一套, 技术选型可以参考
    - (主播)采集推流: iOS LaiFengiOS/LFLiveKit Android LaiFeng-Android/SopCastComponent
    - (上传)流服务器: SRS
    - (观众)播放器: App 端 Bilibili/ijkplayer 网页端 Video.js
产品
- 站长工具 - 站长之家
  手机版
  - SEO信息查询
  - 网站信息查询
  - 域名IP类查询