• 你可以点击这里查看本文的 Github README 项目链接也是这个哦

多服务应用的架构设计

上一个项目遗留问题和解决方式

回顾 App #1

• 之前的微服务 blog 项目，最大的挑战就是 data
• 之前我们想到了使用 同步 和 异步 的方式
  • 在上层使用同步，最终逐渐会变成单体服务的样子，加了一个服务仍然会有其他服务的依赖 数据 和 延迟
    
• 异步交流主要是通过发送事件信息给事件总线来交流
• 异步通信鼓励每个服务 100% 自给自足。相对容易处理临时停机或新服务创建
• Docker 让服务打包部署更容易
• Kubernetes 配置起来很麻烦，但它使部署和扩展服务变得非常容易

App #1 遇到的痛苦的事情	解决方式！
很多复杂冗余的代码	构建一个中央库作为 NPM 模块，以在我们不同的项目之间共享代码
很难构思服务之间的事件流	在这个共享库中精确定义我们所有的事件。
很难记住一个事件应该有什么属性	使用 Typescript 规定一切 type
真的很难测试一些事件流	竭尽所能的写我们的测试文件
本地机器在运行 kubernetes 和其他所有东西时变得越来越迟钝…	转到云上
如果有人在编辑 comment 后又编辑了另外 5 个 comment，要处理这些并发该怎么办…	引入大量代码处理并发问题

⬆ back to top

Ticketing App Overview

• 用户可以列出要出售的活动（音乐会、体育）的门票
• 其他用户可以购买此票
• 任何用户都可以获取 出售 和 购买 的 lists
• 当用户尝试购票时，该票会被“锁定”15 分钟。用户有 15 分钟的时间输入他们的付款信息。
• 锁定时，其他用户无法购买门票。 15 分钟后，票应该“解锁”
• 如果票价未锁定，则可以编辑票价
  
  

⬆ back to top

数据资源 变量 字段 类型 定义

⬆ back to top

Service 类型

• 使用单独的服务来管理每种类型的资源
• Q：我们应该为每个微服务应用程序都这样做吗？
• 可能不是？取决于您的用例、资源数量、与每个资源相关的业务逻辑等
• 也许 ‘feature-based’ 的设计会更好

⬆ back to top

事件和架构设计

• 架构设计
  
• 事件设计
  

⬆ back to top

创建 Auth Service

• 接口设计
  

⬆ back to top

Auth K8S Setup

• 经典 docker -> k8s 命令一顿搞

cd ticketing/auth/
docker build -t heysirius/auth .
docker login
docker push heysirius/auth
cd ../infra/k8s/
kubectl apply -f auth-depl.yaml
kubectl rollout restart deployment auth-depl
kubectl get deployment
kubectl get pod
kubectl logs auth-depl-7c7879db66-mwz79
kubectl describe pod auth-depl-7c7879db66-mwz79
kubectl exec -it auth-depl-7c7879db66-mwz79 -- cat index.js
kubectl get services

⬆ back to top

添加 Skaffold 自动化

See ticketing/skaffold.yaml

cd ticketing/
skaffold dev

⬆ back to top

Ingress-Nginx Setup

kubectl get ingress
kubectl describe ingress ingress-service

⬆ back to top

Hosts File and Security Warning

Hosts File

• Open hosts file

code /etc/hosts

• Add 127.0.0.1 ticketing.dev to hosts file

Security Warning

• Goto Chrome - https://ticketing.dev/api/users/currentuser
• Unskippable HTTPS warning in Chrome?
  • type thisisunsafe

⬆ back to top