2015年夏天的春天〜即使是夏天，我去了春天

1 年 ago

宇, 华

1 minute

2015年夏季去了夏天中的春天。

微服务架构设计

幻灯片

MSA的两个方面

文化面

分散设置与整合

如何保持功能的持续性=服务
通过协调服务之间
通过消息传递进行整合→使用标准协议连接（如HTTP、REST…）

持续与分权 yǔ

软件开发并不是目标。
运营服务成为了我感兴趣的内容。

承认每个领域的自主性，否定标准化

大家都讨厌标准化框架的对吧。

虽然无法对整个服务进行重建，但可以部分重建。

以舍弃为前提的架构。

为何而出现？

将Web服务进行传统化

亚马逊超级大

服务共享的普及化→云端

现在可以通过编程来管理服务。

MSA不是理想主义，而是现实解决方案。

因为大家都采用了相似的架构，所以我给它取了这个名字。

理解MSA

技术管理论比技术论更重要。 bǐ .)

MSA得益于卓越的技术。

有一个叫做MSA的东西，并不意味着使用它就能解决问题。

不是粒度问题，而是关系问题。

系统和子系统的例子很多，但不必纠结于粒度。

SOA与MSA

理想の世界
全体最適

MSA:ボトムアップ

現実解
部分最適の集合
実際にはこうするしかないよね、的なある種の諦め

建筑是治理的手段。

あるシステムとシステムのやりとりがバッチだったり
それぞれバラバラに統治されてる

SOA＝君主制

標準化による統治
偉大な王がいれば可能
企業全体を見渡して全体最適を考えられるならできる
変化の激しいWebサービスとかだとうまいこといかない

MSA＝民主制

各システムにそれなりにできる人がいる

通常人类的问题！！！

MSA并不是银弹

有識な市民の存在

SOA和MSA是相辅相成的思维方式。

架构的反击

近年来，我们已经能够构建起灵活性强的架构。
在过去，我们主要依赖流程（即敏捷开发）来应对。

可以创建具备容量规划功能的架构。

敏捷开发也好，最终还是觉得只要做自己能做的事情就好。

请用汉语将MSA的设计改述一遍。

MSA是针对复杂问题的解决方案之一。

前提：在企業系統中的應用

保留并兼容传统与变革

领域 = 变化的边界线

并不是说存在着“域名”，而是在实际上存在着边界，并对边界进行了命名，就称之为“域名”。

寻找变化的界限是关键。

车辆的零部件因接触地面而磨损，所以与车身本身采用不同的材质，而且有许多不同的制造商。

变化的界限通常不明确，但只能划定一条线。

我只需要一个选项，把以下内容用中文进行本地化改写：
只要一次获取域名就不想改变

平台

如何取得平衡

目前，先确定一个平台会更容易。

把它变成单一平台也很困难。

未来需要着手解决的是私有PaaS的一部分。

阿拉伯标准语（MSA）的实例

我认为电子商务网站很容易理解。

电子商务网站具有相当大的社会责任。

企業已经有了企业系统，通过开设电子商务网站的模式，与传统系统进行协作。

因为电子商务网站的功能层中有各种过程，所以采用微服务架构更容易实现。

因为境界很明确，所以可以通过云端部分应用平台。

服务和运营实体的接近度也是重要的因素。

总结

如果变成了MSA，可以使用。

域名和平台的平衡很难找到。

过于独立会增加浪费。

是否有许多有良知的市民非常重要。

不只有Spring Boot！

在大型企业中，对最新的前端架构的挑战

最近有越来越多的人对用户体验产生了兴趣。

由于域建模在大规模情境下不加以抽象化会变得复杂难懂，因此选择不进行。

无法更换中间件的问题 de

应用程序受到了影响，情况不妙。
嗯，那是当然的啦。

精心开发日志输出功能。
.)

由于是事务脚本，因此将输出所有的跟踪日志。
这几乎可以解决与应用程序相关的故障。

为什么选择采用Spring MVC？

ミドルウェアは変えられない → Spring MVCにするだけ

在我之前听到的那个会议上，听到了有关精神算法（MSA）的讨论，让我感到特别兴奋。所以，难道不应该选择MSA吗？

午餐会议：介绍Wagby。

我非常享受着Jasmine Soft公司提供的冲绳便当，味道非常美味。

Wagby 是一种开发工具。
它是一个自动生成工具。

模型基础

我觉得Wagby在听到他们的交谈时非常出色，他们的能力和实现的成果值得赞赏。但我觉得他们一定很辛苦地制作了它。另外，我也不太确定这个投资是否能够回收成本，不太清楚它是否能够畅销。

微服务的微观

主要讲题。
因为设备故障，屏幕没有显示出来。哈哈。

我想填补代码和生产之间的鸿沟。
它们非常重要。

我被称为开源。
(Wǒ .)

如何快速且频繁地进行到生产环节呢？

云计算

过去排队的人越来越多，我们要尝试在软件开发中引入精益开发。

将 Dev 和 Ops 这两个团队合并为一个团队，目的是加快进度。

开发团队与运维团队的对立

不仅限于系统操作或软件，而是包括所有东西。

顾客想要建立一个平台→太疯狂了

软件开发人员不需要关心物理芯片和电力发电，因为这已经变得非常普遍化。
考虑这些事情是没有意义的。

不需要管理基础设施。

只要使用GCP或任何其他平台，就不需要担心低级问题。

重要的是反复揭示域和功能。

如果不是谷歌之类的，也许可以有足够的方式。可扩展性的艺术。

据说80%的互联网流量都是由Netflix所占据的。

尽可能自动化，消除纵向比较。
代码库变得更小。

一旦成为 MSA，域名就变得非常重要。

进行多次轻量级单元测试比花一个月时间做优秀的单元测试更重要。

观察定位决策行动
创新大数据文化云

军事领域的术语。
也适用于软件。

一旦开始提供细节服务，接下来就会出现一些问题。

服务注册与发现

春天依赖注入与大规模项目，春天真的会来吗？

呼呼！

有500人的规模，存在语言障碍和技术水平障碍。

最初希望尽可能地使用Spring进行构建。

构成的变迁

MariaDB转换为Cassandra、Elasticsearch

@Chachable → 发现了一个错误

关于 DI 的话题

要求很高哈哈

希望响应速度为100毫秒。

你是否在使用@Autowired ？

如果是春天，我想要受到Autowired的好处。

然而。。。

瞬間的にスケールしたい

プロジェクト間の依存関係
DIって？

其实是不是变得一团糟了呢？

为什么要做DI呢？

実装とインターフェース分離
フレームワークの設定は@Importで管理

速度も考慮

ComponentScanしない

保证模块化

warで一個にすると楽だけど…

组件扫描自动装配令人振奋不已。

当有大约十人使用时，它可以轻松使用，没有任何问题。

發生問題

推移的依存解決で色んなもんが必要になるから…
ありがたいけどありがたくない

起動時間遅い

basePackageで対象パッケージを指定して解決
コンストラクタでDB読み込みをするアホがいた

プラグイン的に使いたい

プラグインが要求するものが分からない

人口增加＝罐子数量增加

不进行ComponentScan

为了注重速度，避免扫描
@Component将由自己管理
但插件将例外地进行扫描

合理利用@Configuration。

正确使用 @Import

由于@Qualifier太复杂，我不想使用。

我创建了 @GuardedConfiguration。
这样可以防止重复注册。

还有更严格的规则。
也适用于Config。

结果

依存が透過的になってわかりやすい

综述

当人数增加时…

成果物が増える

追求小而精致的重要性！！！

给附赠品

听取对方的意见

让我们对开发者野口保持高度敏感！

なんか怒ってる、諦めてる（そんな雰囲気）

问答

A. 2，3分くらいは速くなった

漂亮的应用

摇滚乐！

要开始使用Spring Boot

etc…

据说Spring开发团队为了大家日夜努力工作，所以他们团队的人都秃顶了呢ｗ

Josh的现场编程太流畅了，太厉害了。

使用Spring Framework/Boot/Data完全利用～Spring Data Redis编程技术～

关于Spring Data Redis的讨论。

Spring Data Redis是一种与Redis数据库进行交互的框架。

通过使用RedisCacheManager，可以与缓存机制进行协作。

@缓存可用

选择使用Redis的配置选项

Redis 3.0から
ちゃんと可用性を考慮すると6大のノードが必要

Redis Sentinel
Load Balancer

春天 + Redis 集群

春季还没有进行处理。

春天 + Redis 哨兵（访问主服务器）

需要至少有一台在启动时连接到Sentinel才能无限启动。

春天 + Redis Sentinel (到slave的访问)

需要与Slave建立独立连接。

春天 + VIP

简洁。
只需要看一台就可以了。
MultipulJedisConnection

总结

为了确保实际运用，需要在一定程度上进行定制化。

《春天适用的反面模式与最佳实践》（暂定）

你用它做什么？

日曜プログラミング

我对春季的应用范围扩大有着很明显的实感。

JetBrainsも

糟糕的经验或技术

社内标准开发时：社内开发标准的制定和实施期间

ナレッジベースがでかい方がいい
現状を見るとよかった

Wicketを採用した → BAD!!!

フレームワーク縛ってしまった
IEのモーダルウィンドウとかに対応しようとして辛かった

一个典型的Spring项目的架构

至少应该让View能够灵活变换。

最好在组织中分享采用框架的优缺点。

我們使它變成了像是 Struts 的結構配置。

合理的的职责划分

“奥利奥框架” lì ào jià)

我所使用的框架的常见问题

Javaのバージョン上げられないとか

継続サポートない
新しい技術に対応できない
フレームワークのクセが仕事になる

それバグじゃね

不要再用我自己的框架了！绝对不行！

整理了不好的经验教训

基本のレイヤデザインにしたがおう

最佳实践

很难说是最好的，但可以选择更好的。

抽象化存储库层，以实现可切换数据源。

制作时要意识到可拆卸实施的可能性

虽然还有很多遗留的部分，但开始使用Spring让我感到非常兴奋！！

绝妙的微服务

几乎不需要编写代码的Spring Cloud
需要Spring Boot的知识

尽管创建单一应用程序比较复杂，但它带来的优势超过了这个复杂性。

去年JJUG CCC Fall 2014的实际操作非常受欢迎，与之前相似。不过再看一遍后，仍然感到非常棒。