业务应用开发，通常是以业务价值为导向，重视高效迭代和正确性，对软件性能要求则相对不高。

基于 JavaScript(TS) 的全栈架构 & 单一代码库

参考文档

• 深入：微任务与 Javascript 运行时环境

参考文档

• OAuth 2.0 的四种方式

许多公司有诸如业务中台、业务支撑平台这样的部门，研发的工作内容是持续满足业务部门提出的需求。

• 研发人员支撑业务需求迭代，能受理多少需求？支持多频繁的迭代？

个人对业务应用后端的一个构想：

1. 后端应用核心在于业务逻辑，通过 API 与下游提供数据交换
2. 业务逻辑：囊括业务所需的一切逻辑，负责与数据库或上游服务进行数据交换

一般情况下，开展业务的团队需要两套 SSO（单点登录）系统，一套面向客户，一套面向团队内部；因为

1. 面向客户的服务通常存在多个，大部分有登录鉴权或获取客户信息的需要
2. 面向客户的服务越多，相应的后台管理应用也会越多，需要对操作人作相应鉴权
3. 多个系统各自实现登录鉴权，既不安全也不高效，因此需要两套 SSO

三周前前任雇主与我提了分手（含分手费），一别两宽，一路走好 #言重了 😅

动身见过千里之外的朋友，亦有贵客自远方来造访寒舍 #感恩 😄

陪伴娃的时间稍多，见证了亦青宝宝解锁一些技能 # 👨‍👩‍👦

得益于今年的风控管理，目前现金储备宽裕，虽然投资处于亏损状态 # 🍂

异常现象

• 个别应用会根据请求头 X-Forwarded-Port 来确定重定向地址，如 Jenkins 「系统管理」相关链接跳转，X-Forwarded-Port 不准确会导致跳转异常；

此前，网络架构上使用入口 Nginx + Kong，相关配置简单，可快速上手。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

# 入口 Nginx 配置实例
server {
  listen 443 ssl;
  ssl_certificate   ……;
  ssl_certificate_key ……;
  server_name *.fangcha.net;

  location / {
    proxy_read_timeout 300;
    proxy_pass http://127.0.0.1:8000;
    proxy_http_version 1.1;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Port 443;
    proxy_set_header Host $host;
  }
}

Nginx 中强制 HTTPS 访问常用配置

1
2
3
4
5

server {
  listen 80;
  server_name example.com;
  return 301 https://$host$request_uri;
}