マイクロサービス＆サービスガバナンスの進化について話します

インターネットアーキテクチャの進化のこれらの二日間は、理解するのは簡単、かつマイクロサービスの出現に非常に興味があったので、簡単な照合及び要約の知識。

この記事では、簡単にインターネットアーキテクチャの進化を説明し、サービスとして導入され、最終的にはマイクロサービスと最新のサービスグリッド（サービスメッシュ）を紹介します。
---------------------

インターネットアーキテクチャの進化

統合アーキテクチャ

コンピュータソフトウェアの初期の開発では、一般的なデスクトップソフトウェアは、インターフェースをこのアーキテクチャを使用しているか、それかどうかのパッケージに配置されているビジネス・プロセスやデータ処理です。この事実アーキテクチャだけでなく、それは十分に簡単ですので、それは、その優れたアーキテクチャと言えます。

MVCアーキテクチャ

しかし、ブラウザの登場は、Webアプリケーションが生成されますと、Webアプリケーションの機能は、インターフェイスの一部であり、ブラウザに表示され、容器のサービスにおけるサービス処理、ページがに対処するための一般的な使用のCSS + JS + HTMLの技術を示し、その後、エンド缶ジャワ、分離された前端と後端を生成言語、等PHP。Webシステムの場合は、1つのアーキテクチャは、MVCアーキテクチャを生産する分離の前後端の開発ニーズを満たすことができません。

加えて、前後端を分離する問題を解決するため、MVCは、本当の意味でのアーキテクチャに考えられ、また、ビジネスロジック、データの新しい開発モデル、、、組織コードを分離するアプリケーション全体を作成するためのインタフェース表示方法を紹介より良い定義が、唯一のすべてのレベルとの間の結合を減少させるだけでなく、再利用のすべてのレベルを向上させます。

アプリケーションモジュールが増加して、アプリケーション全体がますます肥大化になってきた順番にマルチアプリケーションアーキテクチャを生成するように、しかし、アプリケーションの成長の大きさと、また、維持することがより困難です。

マルチアプリケーションアーキテクチャ

マルチアプリケーション・アーキテクチャは、ビジネスの特性に応じて複数のアプリケーションに元のアプリケーションであり、非常にシンプルです。例えば、主要な電力供給システムは、ユーザシステム、商品システム、注文システム、評価システムが含まれていてもよいというように、我々は別の申込書をそれらを分離することができます。マルチアプリケーションアーキテクチャは、アプリケーション間で独立しており、彼らはお互いを呼び出すことはありませんいます。

マルチアプリケーションが肥大化したアプリケーションの問題を解決するが、独立したアプリケーションであり、いくつかの一般的なビジネスやコードを再利用することはできません。

分散アーキテクチャ

大規模なインターネットシステムでは、通常、複数のアプリケーションが含まれており、多くの場合、アプリケーション間の一般的なビジネスがあり、また、アプリケーション間の呼び出し関係があります。また、このような利用者の急速な成長に対処する方法として、大規模なインターネットシステムのための他の課題は、その上のより安定した製品のアップグレードを維持し、方法、R＆Dチームの高速反復的な製品開発を管理する方法があります。

したがって、我々は、ビジネスやアプリケーションを分離したい、維持・拡大しやすい良いビジネスの再利用、モジュール性を、得るために、ビジネスはもはやアプリケーションに属している、それだけでメンテナンス用のスタンドアロンサービスとして。肥大化したアプリケーション自体は、もはやモジュールのスタッキングではありませんが、モジュラーサービスコンポーネントの組み合わせを一緒に。

のサービス

サービス指向の機能

その上述の分散型アーキテクチャは、サービスが向いています。サービスは、主に次のような特徴を持っているとして、私たちは、総括してみましょう：

事業別のアプリケーションは、サービスに分割しました
各サービスは独立して展開することができます
サービスは、複数のアプリケーションで共有することができます
サービスとの間で通信を行うことができます

サービス指向のメリット

だから、企業の利益とサービスには、それを何を採用しているしていますか？

明確なシステム上のアーキテクチャ
頻繁な放出によって引き起こされるリスクを排除し、ユニットとしてのサービス・コンポーネントをアップグレードするために安定したコアモジュール
開発と容易な管理
個別のメンテナンスチーム、作業明確な、明確な責任
サービスの多重化、コードの再利用
拡大するのは非常に簡単

実装のサービス

あなたは、サービス指向の言葉を実装する場合は、最も一般的な方法は、RPCフレームワークを使用することです。サービスコンポーネントは、通常、異なるサーバー上で実行されるため、その解決すべき第一の問題点を達成するためには、RPC ** **リモートサービス呼び出しのサービスです。RPCは、次のような多くの同様のプログラムを、持っています：

JavaのRMI
ウェブサービス
ヘッセ
Http
倹約
... ...

サービスの挑戦に直面して

リモートサービスコールの問題を解決するための最初の必要性の上記のサービスを実現するために、加えて、解決するために、他の多くの問題があります。

サービスのより多くの複雑な構成管理
ルームサービスの依存関係の複雑
サービス間のロードバランシング
サービスを展開
サービス監視
サービスのダウングレード
認証サービス
ライン上および組立ラインオフサービス
サービス文書
... ...

サービスマネジメント

上記のサービス指向は、実際には、サービスのために、サービスガバナンスが重要です。その後は良いガバナンスのプログラムおよびサービスが、それはありませんか？答えはイエスであり、多くの人々は、このフレームワークを使用している、と彼は-dubboです。ダボはRPC機能を備えたサービス管理フレームワークです。

ダボは、より完全なサービス管理プログラムを提供するので、あなたは、サービス指向のビジネスを実装したい場合は、その後、ダボは良い選択です。ここでは簡単には、サービスガバナンス関連のプログラムをダボ。

サービス検出登録

服务治理领域最重要的问题就是服务发现与注册。dubbo中引入了一个注册中心的概念，服务的注册与发现主要就依赖这个服务中心。

dubbo注册中心服务注册发现的具体过程：

服务提供者启动，向注册中心注册自己提供的服务
消费者启动，向注册中心订阅自己需要的服务
注册中心返回服务提供者的列表给消费者
消费者从服务提供者列表中，按照软负载均衡算法，选择一台发起请求

服务监控

集群容错

负载均衡

Random Loadbalance
RoundRobin
LeastActive
ConsistentHash

dubbo服务治理优势

注册中心只负责注册查找，不负责请求转发，压力小
注册中心宕机影响消费者，消费者本地缓存服务地址列表
注册中心对等集群，宕掉一台自动切换到另外一台
服务提供者无状态，可动态部署，注册中心负责推送
统计无压力，本地内存中累计次数，每分钟发送注册中心
消费者调用服务者，自动软负载均衡
通过服务中心可追踪依赖关系
监控中心为扩容和降级提供依据
可启用acl机制进行鉴权
与Spring整合，接入简单松耦合
多种序列化协议支持

dubbo的不足

消费者仍需要依赖配置中心
消费者仍需要依赖jar包配置provider
提供者文档管理功能缺失
无统一入口
不支持OAuth2.0
内部鉴权不方便管理
无外部应用鉴权
接口基本裸奔，无法直接对外暴露服务
IT治理不方便

微服务

现在很多人都在谈微服务，那么到底什么是微服务呢？这里谈谈我对微服务的理解。

微服务有两个核心：

微：服务的粒度要细，即服务要细化到API
服务：提供好服务，要让用户感到好用(要做到这一点很不容易)

微服务（Microservices）是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。

微服务架构 ≈ 模块化开发 + 分布式计算

从上面这幅图看出，微服务特别简单（好的架构就应该简单），我们把服务再拆分成一个个API，API是一个完整的功能。然后我们把API扔到一个“云上”，然后用户就可以到“云上”获取所有API的服务，这个“云”保证能提供好的服务。

我们可以看到，有了微服务之后，服务对用户来说变得特别简单，而且上面dubbo的不足之处在微服务这里都解决了。使用者不再需要依赖任何jar包，不再需要去注册中心查找服务，不再去做鉴权处理，不用担心服务挂掉，不用担心不会使用服务，所有的问题这个“云”都解决了。这也是微服务的核心之一，提供好服务。

说到这里，大家就应该大体知道该怎么做微服务了，图中的“云”是关键。下面我们就慢慢拨开这朵云。

微服务的实现

微服务的关键是服务网关，所以，上面提到的“云”就是服务网关。要做微服务，我们先定义一下微服务需要具备的特点。

常见的微服务组件及概念：

服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
服务发现：服务调用方从服务注册中心找到自己需要调用的服务的地址。
负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。
服务网关：服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。
配置中心：将本地化的配置信息（properties, xml, yaml 等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。
API 管理：以方便的形式编写及更新 API 文档，并以方便的形式供调用者查看和测试。
集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
分布式事务：对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。
调用链：记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。
支撑平台：系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。现在，可以通过 Docker 等工具来中和这些微服务架构带来的弊端。例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以我们两年的实践经验，可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。

微服务架构的优点：

降低系统复杂度：每个服务都比较简单，只关注于一个业务功能。
松耦合：微服务架构方式是松耦合的，每个微服务可由不同团队独立开发，互不影响。
跨语言：只要符合服务 API 契约，开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响。
独立部署：微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得 CI／CD 成为可能。
Docker 容器：和 Docker 容器结合的更好。
DDD 领域驱动设计：和 DDD 的概念契合，结合开发会更好。

微服务架构的缺点：

微服务强调了服务大小，但实际上这并没有一个统一的标准：业务逻辑应该按照什么规则划分为微服务，这本身就是一个经验工程。有些开发者主张 10-100 行代码就应该建立一个微服务。虽然建立小型服务是微服务架构崇尚的，但要记住，微服务是达到目的的手段，而不是目标。微服务的目标是充分分解应用程序，以促进敏捷开发和持续集成部署。
微服务的分布式特点带来的复杂性：开发人员需要基于 RPC 或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。
分区的数据库体系和分布式事务：更新多个业务实体的业务交易相当普遍，不同服务可能拥有不同的数据库。CAP 原理的约束，使得我们不得不放弃传统的强一致性，而转而追求最终一致性，这个对开发人员来说是一个挑战。
测试挑战：传统的单体WEB应用只需测试单一的 REST API 即可，而对微服务进行测试，需要启动它依赖的所有其他服务。这种复杂性不可低估。
跨多个服务的更改：比如在传统单体应用中，若有 A、B、C 三个服务需要更改，A 依赖 B，B 依赖 C。我们只需更改相应的模块，然后一次性部署即可。但是在微服务架构中，我们需要仔细规划和协调每个服务的变更部署。我们需要先更新 C，然后更新 B，最后更新 A。
部署复杂：微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。此外，我们还需要服务发现机制，以便服务可以发现与其通信的其他服务的地址。因此，成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。
总的来说（问题和挑战）：API Gateway、服务间调用、服务发现、服务容错、服务部署、数据调用。

微服务要解决的问题

上面提到了，dubbo还存在一些问题，其实dubbo存在的问题就是微服务要解决的问题，这里再总结一下。当然，dubbo和微服务的侧重点不一样，dubbo侧重于内部接口之间的RPC，而微服务则侧重于对外提供服务。

统一入口
安全控制：防刷限流
统一鉴权：应用鉴权、用户鉴权、OAuth鉴权、ACL
协议转换：http、dubbo、Protobuf
API配置管理
API上线、下线
API与服务接口映射
监控与报警
整体架构的可拓展、高并发、分布式
服务容器自动收缩、扩容

实现方案

负载均衡层：nginx/lvs/F5
微服务层

　　　　高性能服务网关;
　　　　统一入口、API配置管理、分流鉴权、服务监控、协议转换;
　　　　API映射、OAuth2.0、API文档管理;
　　　　分布式、可拓展;

服务治理层

　　　　成熟的服务治理框架dubbo;
　　　　MQ服务之间解耦;

弹性云

　　　　服务docker化;
　　　　基于访问压力的实时集群调度与管理;

弹性云

这里简单介绍一下弹性云的概念，微服务要想提供好服务，保证API不能挂掉并且有好的性能，需要很高的运维要求。这里的弹性云便是自动化运维解决方案，对访问压力进行监控，根据监控解决调度应用的发布和回收。

服务网格（Service Mesh）

2017 年底，非侵入式的 Service Mesh 技术从萌芽到走向了成熟。

Service Mesh 又译作“服务网格”，作为服务间通信的基础设施层。

如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。

Service Mesh 的来龙去脉：

从最原始的主机之间直接使用网线相连
网络层的出现
集成到应用程序内部的控制流
分解到应用程序外部的控制流
应用程序的中集成服务发现和断路器
出现了专门用于服务发现和断路器的软件包/库，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，这时候还是集成在应用程序内部
出现了专门用于服务发现和断路器的开源软件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
最后作为微服务的中间层 Service Mesh 出现

Service Mesh 有如下几个特点：

应用程序间通讯的中间层
轻量级网络代理
应用程序无感知
解耦应用程序的重试/超时、监控、追踪和服务发现

Service Mesh 架构图：

关于微服务和服务网格的区别，我的一些理解：微服务更像是一个服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信，以及和 DevOps 更好的结合。

---------------------
Reference:
1，微服务架构初探

2，浅谈服务治理与微服务

3，什么是Service Mesh（服务网格）