我去参加了第六期的「微服务见面会」

2 年 ago

科, 雅

2 minutes

我们在2017年1月19日的每日库存排行榜中入榜了。

【毎日自動更新】Qiitaのデイリーストックランキング！ウィークリーもあるよ_-_Qiita.png

最近参加的活动回顾：
1. 参加了「微服务聚会vol.2」，以下是我的笔记。
2. 参加了「微服务聚会vol.4」。
3. 参加了最新的「微服务聚会vol.5（API Gateway & BFF）」（速报）。

你无意中每隔一次参加一次呢。忘记自己参加了第5次的活动了哈哈。

Connpass的活动页面

虽然有些时间间隔，但我希望能继续定期举办。
想登台的人请直接回复。
by @qsona さん

AWS上的微服务，由@Keisuke69さん

西谷圭介 @ 亚马逊网络服务

专业解决方案架构师

2月份将推出《无服务器应用开发指南》。

微服务的关键点

単独で実行できないのは適切に設計されていない

通过在独立且分散的高负载功能单元上进行扩展，可以实现成本效益较高。

複雑化したら分割する

多言語

チーム（機能）にはそれぞれの問題に対して適切なツールを選択する自由がある
OS、言語、各種ツールに至るまで最適なアプローチを目指せる

検索：Elasticsearch / Solr
ソーシャル：グラフDB
ログデータ：Cassandra
セッション：Redis

在AWS中，有大约100个服务，而且这些服务还分为多个团队进行开发。
每个团队没有内部标准的开发流程。

詳細は外部のコンポーネントに公開されない

DevOps

マイクロサービスにおける組織原理

†在AWS中：没有仅仅负责运营的团队。开发团队也负责承担着值班的责任。

俊敏性

狭い範囲のコンテキストで活動＝サイクルタイムが短い
システムもシンプル
パラレルな開発とデプロイが可能

イノベーション

選択に対する権限と責任を持つのでイノベーションを起こしやすい
DevとOpsの対立がないため、効率化やイノベーションが起こしやすい

拡張性

適切に非干渉化されてていることで水平方向に単独にスケールできる

可用性

ヘルスチェック、キャッシング、隔壁、サーキットブレーカーと言った仕組みは全体の可用性を向上させる

题目

システム数が増える
協調動作の難しさ
コンポーネント間のコミュニケーションメッセージ増によるレイテンシ低下
ネットワークの信頼性は無限ではない、帯域も無限ではない

移行が大変

モノリシックなシステムの分割は難しい

組織

組織体制の変更が必要になるが、それは大変なこと

アーキテクチャの難易度

非同期通信
データ整合性
やっぱりココが一番の課題
サービスディスカバリ
認証

運用の複雑さ

架构 (jià

一个简单的模式

CloudFront – ALB – ECS – 数据存储（ElastiCache，Dynamo）
|
S3

云前端 – 应用负载均衡器 – 弹性计算服务 – 数据存储（ElastiCache，Dynamo）
|
简单存储服务

CDN通すことでレイテンシが上がることもある
キャッシュとの併用を検討

ECSとAutoScalingをALBとともに使うことが多い

ALB(L7LB)でアプリレベルの情報をルーティング
コンテナインスタンスにリクエストを分散
ECSのコンテナを負荷に応じてスケールアウト／インする

集装箱的优点

軽量で早い
ポータビリティと関連して開発サイクルも早く

Efficient
一貫性のある環境
バージョン管理出来る

Docker的特点

Run

云服务器

まだTokyoにきてないけど、FargateでEC2の管理もいらなくなるよ
EKS(Kubernetes)も発表されています

数据存储

Memcached, Redis
ElastiCache
DB負荷の軽減

RDBMS

無限のスケーリングには向いていない
Amazon RDS

NoSQL

水平スケーリングをサポートするものが多い
テーブル結合ができないのでロジックの実装が必要になる場合も
Amazon DynamoDb, KynamoDB Accelarator(DAX)

API的实现

異なるバージョンが混在すると大変

亚马逊API网关

バックエンドとしてLambdaが使える

无服务器

スケーリングと高可用性の担保が大変

CloudFront - API Gateway - Lambda - datastore
   |                            (ElastiCache, Dynamo)
   |
  S3

在AWS上如何处理课题。

服务发现

ハードコードするとスケールできない

メタデータをどこに置くか

ALBを利用したサービスディスカバリ

DNS(Route53)のサービスディスカバリ

VPC単位の振り分け

ECSイベントストリームを使用したサービスディスカバリ

CloudWatchイベントで拾ってキック
LambdaでRoute53に登録
これが一番多いかも

DynamoDBを使用したサービスディスカバリ

DNSキャッシュの問題がない
自由度が高い
実装が大変
DynamoDBストリームを活用して他のサービスへステータス変更を反映

イベントベースのアーキテクチャ

イベントで処理する
いわゆる結果整合性とも関連
Dual Write Problem
Event Sourcing

状態の記録ではなく状態の変更「イベント」を記録
Amazon Kinesis
kinesisにpublishして他サービスはsubscribe
S3にログを残す
トランザクションログの仕組み

监控

ログファイルの一元化
CloudWatch LogsかS3に保存可能
ECSはCloudWatch Logsに一元化できる

分散追踪

複数サービスに分散したリクエスト処理を透過的に追える

在LogWatch之前是Kinesis FireHorse – 呼呼呼

限制网络速度

大事だよ

重试

Exponential back offもしくはフィボナッチ数列を利用したリトライ感覚の調整
更に乱数でゆらぎを付けて重ならないように

LT：通过@hashedhyphen的云医疗业务系统和微服务的发展历程。

云电子病历系统的讨论

基盤はAWS

到达这里的道路

在首次发布之前。

メインロジックで実現させようとすると厳しかった

Threadとか試したけど……
別アプリケーションとして分離
JVM上でScala + Skinnyでスレッドアプリケーションンを実装
Microservicesちっくな構成へ

障害検知時

メインロジック内のプロトタイプ版が動く！

财务功能发布之前

マイクロサービスっぽい作りになっていたから自由度のある技術選択が出来た

总结

エンジニアの伸びしろ！

从前端的角度看，通过@taka_ft的microservice和从后端的角度看的microservice。

藤井孝裕 @ 楽天旅行

在楽天内部，采用的架构因服务而异。

作为一项服务

ここまではWEBとモバイルがあって、100以上のAPIを利用する

API（内部APIを直接利用）

第一阶段

機能別で複数のモノリシックなアプリに分割
その後フロントエンドとバックエンドに分割

第二阶段

Microservicesっぽくなってきたが、どんどん品質が下がっていった

第三阶段

（就在前一天发布新闻稿的当天）为了更新网站首页的努力

API GatewayにKong

组织

日本人は2, 3人

UI组件

レスポンシビリティを明示的に定義

どこまでフロントエンドでやるか、どこからAPIからもらうか

フロントエンドの「使いやすいレスポンス」の要求

バックエンドの「汎用的でシンプルなレスポンス」の希望

これらのバランスを取る

API Gatewayはフロントエンド（UI）チームの管轄

ただし状況によってはバックエンド側に持っていくことも検討するつもり

“微服务还够用吗？”由@qsona先生发表

我之前在POSTD上发布的翻译文章。

大部分的初创企业不应该采用微服务。

我們沒有銀色的彈藥。

在解决「团队间依赖性」这个问题上，微服务和其他方法是不同的。松耦合和分布式是不同的概念。

当组织规模扩大时，会有多个团队共同操作一个代码库，进而产生对微服务的渴望。

但是，只需要将单体分割就足够了。

团队是什么

自律的に動けるべき

チームが増えるとコミュニケーションコストや、しがらみ

チームの分割は目的にそった分割を行う
悪い分割の例： Dev / Ops
依存度が低いほど自律的に動ける
High Output という本

使命型組織／技術型組織

Micorservicesは使命型組織
組織間が密ならサービス間も密になる

把話题转回去

大きなモノリスになるとやはり分割は難しい

ドメインの意識は必要

マイクロサービス設計しなくても「マイクロサービス精神」で開発すると効果的なのではないか

FiNC一开始就选择使用微服务的原因。

単独の事業にできるような一つ一つのサービスを組み合わせて提供してきたから

稍后会回来读一遍并进行修正。
也要添加一些资料路径之类的。