Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

班会第 52 期 #64

Open
ufologist opened this issue Mar 21, 2017 · 0 comments
Open

班会第 52 期 #64

ufologist opened this issue Mar 21, 2017 · 0 comments
Labels

Comments

@ufologist
Copy link
Member

  • 技术
    • 从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
  • 产品
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant