シリーズ：
ディレクトリ
1はじめに
アーキテクチャの2進化
2.1単一のアーキテクチャ
2.2垂直アーキテクチャ
2.3マイクロサービスアーキテクチャ
3マイクロサービスアーキテクチャモデルの進化の歴史
そして、通信フレーム3.1
3.2ランタイムサポートサービス
サービスのセキュリティ3.3
3.4サービスの監視と警告
3.5サービスの展開
3.6基本的なサービス
3.7保護サービス
3.8リンク圧力測定
4マイクロサービスアーキテクチャモデルパノラマ
5つの問題によって引き起こされます
5.1は、サービスガバナンスの統一されていません
5.2ホイールを繰り返し作成
標準の5.3サービスガバナンスの欠如
概要6
1はじめに
istioを導入する前に、istioは、マイクロテクノロジーサービスシステムで開発されているので、最初のマイクロサービスを話します。あなたは、マイクロシステム技術サービスの合理的な把握を持って戻ってくるとistioを理解するとき、あなたは本当に技術が前方にすべての方法の遺産を動かしていると感じます。
歴史は繰り返すことになりますが、技術が前進することはありません。
本論文では、私はあなたが興味のpptなら、あなたは私に尋ねることができ、同社の技術の後に複数のpptのスクリーンショットから共有にコンテンツをたくさん持っています。
アーキテクチャの2進化
2.1単一のアーキテクチャ
特長：
1つのすべての機能は、プロジェクトエンジニアリングに統合されています
2すべての機能は、Webサーバーに展開し、袋に詰め
データベースの展開と3つの別々のアプリケーション
アプリケーションクラスタおよびクラスタ・データベースを展開することによって、システム性能を向上させるために4
利点：
シンプルな構造、低先行開発コスト、短いサイクル。小規模なプロジェクトのための選択。
短所：
1つのすべての機能は、大規模プロジェクトのためのプロジェクトに統合され、開発拡張し、維持することは容易ではありません
2システムのパフォーマンスは、クラスタ、高いコストを拡張することによって拡張することができます
3技術スタックは限られています
2.2垂直アーキテクチャ
特長：
トラフィックが徐々に増加すると、価格上昇の単一のアプリケーションがマシンますます小さくもたらし、アプリケーションは、効率を改善するために関係のない複数のアプリケーションに分割されます。
利点：
1、関連アーキテクチャのシンプル、低先行開発コスト、短いサイクル、小規模なプロジェクトのための最初の選択
2垂直解像度によって、元の単量体は、無限に拡大しないであろう
スタックは、異なる技術を使用することができる3つの異なるプロジェクト
短所：
大規模なプロジェクトのために、プロジェクトのビジネスドメイン機能と統合1は、開発拡大やコスト高を維持することは容易ではありません
2 系统性能扩展只能通过扩展集群，成本高，有瓶颈
3 单体之间的函数调用过度到系统之间的 rpc 或者 http 调用，服务发现需要单独机制保证
2.3 微服务架构
特点：
1 将系统服务层完全独立出来，并将服务层抽取为一个个微服务
2 微服务遵循单一原则
3 微服务之间采用 RESTful轻量级协议进行传输
优点：
1 服务拆分粒度更细，有利于资源重复利用，提高开发效率
2 可以更加精准指定每个服务的优化方案，提高系统的可维护性
3 微服务架构采用去中心化思想，服务之间采用 RESTful 等轻量级协议通信，相比 ESB 更轻
4 适合互联网产品，产品迭代更加快速和便捷
缺点：
1 微服务过多，服务治理成本高，不利于系统维护
2 分布式系统开发的技术成本高（容错、分布式事务等），对团队技术挑战大
3 微服务架构模型演进史
微服务架构的模型也是一个从简单到复杂的演进过程。
3.1 框架与通信
微服务架构初期，主要的技术诉求是寻找更简单和轻量的开发框架，不同的开发框架意味着采用不同的通信协议。
3.2 运行时的支撑服务
当服务的编写和通信解决了之后，接下来就要考虑一些运行时的支撑服务了。这些服务跟业务去耦，属于基础层的支撑服务，比如网关、负载均衡、服务注册与发现、配置中心等。
3.3 服务安全
解决了服务的通信以及基础支撑后，大体上业务就可以开展了。但是这样裸奔的服务是有很大安全风险的，很多敏感的信息在不经过认证和授权就可以轻易获取到，因此服务安全就加入到了微服务的模型体系中。服务安全主要有两种，分别是 jwt 和 oauth2。
3.4 服务监控和告警
服务在解决了通信、支撑和安全之后，就可以愉快地展开工作了。但就跟判断健康需要做体检一样，判断在线服务是否健康就需要监控和遥测，当工作负载超过了阈值就要告警通知人为介入。服务的监控有很多的维度，常见地有系统指标监控、业务指标监控、服务健康检查、调用链监控、日志监控等。
3.5 服务部署
容器化时代带来了新的运维思路，原有基于虚拟机、物理机的重运维开始向基于容器以及容器编排的轻运维转换，这种转换也带来了服务部署方式的改变。更快、更好、更有效的部署成为微服务架构模型新的挑战。
服务部署需要解决的问题有发布机制的引入、镜像治理、容器治理、卷管理、CI/CD 等方面。
3.6 底层服务
当业务范围越来越广，再大的公司也不可能解决任何技术问题，这时就需要引入一些业界优秀的第三方服务作为底层服务来解决特定问题。有时这些第三方服务并不可能完全适合自己的架构，因此就需要做适当的剪裁。尽管如此，这些第三方服务也构成了整个微服务架构模型中不可或缺的一部分。常用的第三方底层服务有分布式消息中间件、分布式数据访问、分布式任务调度和分布式缓存等。底层服务跟基础支撑服务的区别在于前者更多在业务问题域，而后者则主要是通用问题域。
3.7 服务防护
就像胃口再好的人也不可能一次吃下整头大象一样，编写再好的服务也不可能支持无限的请求。技术人员在处理无限、不可期技术场景的技术方案时，经常的策略是以不变应万变：根据目前的服务负载设置峰值，超过峰值就进行熔断、限流等措施。
熔断如下图所示：
降级如下图所示：
限流如下图所示：
3.8 全链路压测
在上面的介绍中，我们介绍了微服务架构模型的各个维度。本来可以在这里结束，但是想想实在不妥，因为我们缺少了很关键的一环，那便是测试。
全链路压测是稍具规模的科技公司都必须要做的工作之一。它的重要性不言而喻，当业务发展超出预期，系统要具有先知先觉的能力以抵御洪灾。毕竟未雨绸缪总好过亡羊补牢。全链路压测是一个大的话题，因为这里介绍的是 istio，故这里一笔带过，有关 ppt 详情我也照顾篇幅不再赘述，如果有朋友对此感兴趣，可以向我索要。
4 微服务架构模型全景图
下图展示了整个微服务架构模型：
5 带来的问题
マイクロサービスアーキテクチャの導入は、多くのメリットをもたらしますが、それはまた、ガバナンス・サービスの多くの問題をもたらします。次のようにコアの質問は次のとおりです。
5.1は、サービスガバナンスの統一されていません
異なるサービスは、ミドルウェアのガバナンスの異なる方法、および技術基準を導入し、ミドルウェアが異なるこれらの基準を維持します。そのため、運用、保守担当者やインフラが、これは技術会社の限られた人的資源の現実ではない、何回も各ミドルウェアの使用を習得しなければなりません。
5.2ホイールを繰り返し作成
マイクロサービスアーキテクチャは、複数の言語・スタック、マルチテクノロジー・スタックが、コミュニケーション、サポート・サービス、サービスのセキュリティ、サービス監視、ヒューズ/ダウングレード/電流制限の一般的な技術的な問題のためのさまざまなテクノロジー・スタックすることができますが、独自のソリューションを必要とし、それがあります廃棄物のコスト。
標準の5.3サービスガバナンスの欠如
、高品質の職人のオブジェクトのおかげで、ワークショップの時代のようなもので標準化されたサービス管理の欠如、サービスの品質、したがって、全体の技術スタッフのマイクロ管理は個人の能力、経験やレベルに依存している、に起因します。しかし、誰標準化は、技術開発の軌跡と明らかに矛盾していません。
概要6
マイクロサービスの開発は、現在安定し、主流の技術になるが、それはますます厄介な状況になってきていると同時に、問題はますます深刻にさらされています。幸いなことに、サービスグリッド時代、サービスグリッドistioリーダーは着実に歴史の舞台を入力すると、より多くの高温になりますさ。分析下のIXはあなたに簡単に完全な爆発istioを取るしていきます。