本論文では、2つの質問に答えるためにしようとします。
- アプリケーション（例えばアリ雲のような）他のクラウドプラットフォーム上で実行しているクライアントは、どのように実現可能性とワークロードの再配置を評価するためにどのようにクラウドHuawei社、に移動するために、具体的にどのようなプログラムがあり、どのような利点と欠点。
- 心配のお客様のために懸念をバインド「であるクラウド・ベンダーを回避する方法」、顧客がに対処するための技術インフラをより良くする方法を選択する必要があります。
これら二つの質問に答え、「クラウドネイティブ」、「マイクロ・サービス」を時間の新しい概念を考慮すると、容易ではないだけでなく、技術指向の問題、また、組織と管理の側面を、ビジネスを調整します。このホワイトペーパーでは、技術的な側面に問題を軽減します。従来の変換では、また、上に描画することができ曇ったアーキテクチャのフロアプラン、ステップバイステップを行いました。
1パートI：移行とミドルウェアプラットフォーム
展開モデルは、次のようにお客様のアプリケーションシステムがあることを前提としています。
展開図は、クライアントアプリケーションプラットフォームの依存関係を示しています。クライアントアプリケーションを変更せずに、私たちはまず、お客様のプラットフォームに依存コンポーネントを収集する必要があります。Huawei社雲が対応する機能を提供する場合には、Huawei社のクラウド移行が可能であり、一般的に、ワークロードの移行は、実際のコンポーネントに基づいて詳細な分析を必要とする特定の状況および依存に依存し、異なる状況については、以下の簡単な分解を行います。
・プラットフォームの開発/運用・保守への依存。これは、部分的に依存するアプリケーションは、一般的に無関係であり、任意のビジネスロジックを修正せずに使用することが可能です。ただし、異なるクラウドベンダー、異なるの集まりではなく、同じインタフェースの運転経験を提供する能力。1つのクラウドから別のクラウド・ベンダーに移行するベンダーは、顧客の運用・保守要員の運用・保守をもたらすための方法で変更の影響を考慮する必要があります。
・ミドルウェアへの依存。これは、アプリケーションが適切なクライアント/ミドルウェアとコンポーネントの相互作用を選択する必要がある、強い相関の開発と応用に部分的に依存しています。いくつかのミドルウェアは、業界標準である、などのリレーショナルデータベースとして、JDBCドライバを介してアクセスすることができ、これらの移行の標準的なミドルウェア、平均的なユーザーは、自分のアプリケーションを変更する必要はありません。いくつかのミドルウェアは、このようなオブジェクトストレージとして、異なるクラウドベンダーは、顧客がさまざまなアプリケーション、適応クラウド・ベンダーを変更する必要があり、クライアントのインターフェースが同じではありません提供し、業界標準の、ではありません。ミドルウェアに依存転換の努力のために、かなりの程度まで全体的に、通常は新しいアダプタを開発する必要があり、違いミドルウェア、うまく設計されたシステムを保護するために合理的なデザインパターンを採用するかどうか、お客様のアプリケーションの開発と設計時間に依存ワークロードの変換は管理可能です。
・アプリケーションの分野への依存。この作品は、業界で一般的に標準化されていない、別のクラウド・ベンダーを備え、これらの機能は、道を開くために、外部の能力を介してアクセスすることができます。それはまた、Huawei社のクラウドアリクラウド機能、またはそのようなHuawei社のクラウドは、ユーザーがプロバイダを選択することができます提供できる決済サービス、アリ雲、雲テンセント、できるだけプロバイダー、各種の機能を訪問することができます。そして、非標準化されたミドルウェアなど、新しいプロバイダ、新しいサプライヤーの機能を使用するには、新しいアダプタを開発する必要に切り替えます。
・基礎となる仮想マシン、コンテナ、およびネットワークのIaaSの層、コンピューティング、ストレージ、産業、一般的に標準化され、異なるクラウドベンダーでの移行は比較的簡単ですが、通常、クライアントアプリケーションに変更を加える必要はありません。しかし、いくつかの特別なシーンは、まだ対応するメーカーは、このようなビッグゲームの必要性のための専用の画像処理として、適切な技術サポートを提供するかどうかを検討する必要があります。信頼性、性能が異なるベンダーの違いからインフラストラクチャは、ビジネスの要因として考慮されるべきです。
それは、上記の分析から分かるように、顧客がクラウド・ベンダーを心配するバインドされている場合、その後、技術の選択の時間の間に、以下の要因を考慮してください。
•選択ミドルウェアサービスは、標準的なインタフェースを提供します。リレーショナルデータベースの使用は、JDBCをサポートするなど、JMSは、オープンな標準のメッセージングサービスをサポートしています。ミドルウェアアダプタモードにアクセスするための適切なインタフェースを設計するために、コードを開発する場合や、ユーザーが別のクラウド・ベンダーごとに異なる適応インタフェースを開発します。
可能性としてクラウド・ベンダー固有の機能を使用していない、市場で選択した機能の利用可能性を考えてみましょう。ビジネスの観点から、あなたは、製品の競争力を向上させるために、クラウド・ベンダーの独自の特性を選択することができます。可用性は、供給者が独自の機能事業継続開発を提供し続けることができないときことを確認することができます。
また、最も競争力を利用して、顧客の特性を追求し、上記の分析から見た負荷を軽減することができ、 『これら二つの要件を持つ』クラウドベンダー・ロックインを最小限にすることは」矛盾した存在です。一般的には、クラウド・ベンダーのユニークな特性を利用、顧客は最新かつ最も競争力の性質の開発努力と使用を減らすことができ、クラウド・ベンダーを強化し、関係を結合しながら、他のクラウド・ベンダーに移行することは困難です。顧客が自分のミドルウェアおよびビジネス・サービス部門を達成対応する顧客は、より簡単に別のクラウド・ベンダーの間でアプリケーションを移行するので、プラットフォームミドルウェアやフィールドサービスに対応する依存度を減らす必要があり、顧客はまた、開発努力を意味し、高い技術的な難しさ。
いずれの場合も、顧客のシステムが違いのために確保うまく設計されたインタフェースであり、バックアップ選択キーテクノロジーを行い、より柔軟なアプリケーション・システムの移行スペースを持っている顧客を可能にします。
2第二部：移行のマイクロサービス開発フレームワーク
次に我々は、探検ワークロードを分析し、関係の開発フレームワークの移行を結合するために、詳細な顧客アプリケーション、アプリケーションの移行と変換を必要とします。移行サービスプラットフォーム層に対するマイグレーションのこの態様は、より困難で評価すると困難は、多くの場合、より深い交流や開発者を必要とします。同様に、我々は、CSEの枠組みに変換などダボCSEの枠組みの転換、春ブーツとして移行の問題、上のような技術的なフレームワークに問題を軽減することができます。
あなたは2.1を移行する必要があるかどうか
、実現可能性とワークロードの移行を評価する前に、あなたが移行するかどうかの質問に答えるために最初に、フレームのの質問に移行します。
どこに移行？
・オープン性マイクロサービス開発フレームワーク。対応するマイクロ・サービスの開発フレームワークのオープンソース版があるかどうか最初に確認してください。オープンソース版の使用は、コミュニティから学ぶことができるだけでなく、ソースコードを読み取ることにより、詳細を把握する一方で、我々はより簡単に柔軟に将来のニーズに合わせてカスタマイズすることができます。マイクロテクノロジー・サービスの開発フレームワークが閉じている場合その後、簡単にあなたが使用できるかどうか、春の機能を使用できるかどうか、そのような共通のデータベースアクセスコンポーネントのmybaticとして、この枠組みの中で開発された他のオープンソースコンポーネントと統合休止状態、例えば、以下のような春のデータ能力を参照してください春ブーツ、Web技術。最後に、マイクロ・サービスの人気のユースREST通信などの人気の業界標準のマイクロサービスの開発フレームワークのサポートを見て、それはHTTP / HTTP2、RPCの方法の使用をサポートするかどうか、JAX-RS、Spring MVCのおよびその他の人気のインタフェース開発ルールのRESTをサポートしてサポートしていますRESTインターフェースにアクセスします。
・サポートマイクロ「クラウドネイティブ」エリア。マイクロサービスの面で「ネイティブ雲」を理解し、本質的には、さまざまな問題を考慮する必要がなく、ビジネス・コードの開発に注力しているかどうか、マイクロサービスフレームワークのその後の使用に答えることで、将来の「マイクロ・サービス」は、マルチとして、もたらしますときにサービス発見の例として、負荷分散分離して再試行するとき、マイクロサービスインスタンスに障害が発生し、マイクロサービスの障害と結合した（チェーンを呼び出すことによって）（例えば残業のような）位置と、他のマイクロサービスの運用・保守の問題。多くのマイクロサービスフレームワークは、「これらの問題を解決する方法」の機能モジュールとツールを提供していますが、ユーザーがこれらの問題を解決する助けにはなりません。独自のアプリケーションを計画する際に、ユーザーがオンラインビジネスを実行するときに問題があるかわからないときので、ゆっくりと、コストは通常、非常に高く、これらの問題を解決するために、ユーザーの時間を浮上しました。
なぜ移行？
答えは、なぜ移行のどこの部分に移行しますが、移行は上のベースとしてこれらの指標はまだありません。と加入者の増加を満たすために、容器及びマイクロ高速配信やサービスを選択する（かどうかなどはなぜか、そのようなコストや既存の枠組みの問題として、アップオリジナルのビジネス目標に戻って移行するには、ビジネスニーズの将来の発展は、より適切な技術を選択しますように）挑戦、およびします。
2.2ワークロードと実現可能性の評価
別の時間に、開発フレームのためのフレームワークを開発するビジネスニーズ、フレーム廃棄操作しながら、既存のビジネス・ロジックを維持することが望ましいです。理想的には、ビジネス・ロジック・コードは、桟橋のTomcat容器から容器への切り替え、そのようなサービスコード戦争パッケージなどの任意の変更、操作上円滑な切り替え、ことなく、そのままです。
戦争への応用、例えば、アプリケーションとコンテナ間の戦争の依存関係を調べることができます。
フレームワークを採用、コンテンツはサービスリリースの主要部である交流する場所や機能のフレームワークを、存在しなければなりません。TomcatとJettyはコンテナ船のサービスリリースなのでサポート関連のプロトコルおよび仕様なので、ビジネスコードは完全に滑らかに移行することができます。
このようなプロセスフロー、データ・アクセスなどの他のビジネスのコード部分については、サポートされ、それはコードを変更関与していない場合は、移行をスムーズにすることができ、ターゲット・システムは、これらのコンポーネントの実行がサポートされていることを検討してください。
APIによって提供されるツールを使用してコンテナに対応するサービスコードは、その後、コードの変更を必要とするかもしれないTomcatの容器Jettyの容器としてシーンに移行する場合、スイッチング動作が滑らかになります。
当出现目标框架不支持运行依赖的组件，或者服务发布方式没有对等的功能、或者工具API没有对等的API支持的时候，这种切换就会变得不可行。当然实际在选型分析的时候，非常难把握一些细节的不支持情况，不过倒不用悲观，实现一个业务逻辑的方式是有多种可能性的，换一种实现思路去调整实现逻辑，也能够解决单纯从技术上看，无法对等改造的问题。
2.2.1 工作量评估
从上面以war应用在不同运行容器之间的改造可以看出，一个框架改造为另外一个框架的工作量可以从两个维度进行评估：
1. 改造前的业务代码依赖于原来框架/运行时的程度。
2. 目标框架本身对于业务代码采用的技术的支持程度。
再看一下上面例子中，CSE框架的情况。
可以看到，和war应用对比，除了运行时的变化，服务发布的方式变化了，提供的工具API也变化了。 将war应用切换为CSE的工作量主要包含两部分：
1. 将服务发布方式修改为CSE的服务发布方式，即将Servlet定义修改为Spring MVC或者JAX RS或者RPC的方式。
2. 调用工具API的地方，需要分析CSE SDK是否有对等的替换方案，使用CSE SDK提供的API进行修改。
下面表格结合上面的分析，简单的评估了一下各个框架切换CSE的难度对比。这个难易程度只是近似的评估，主要考察可能的改动点多少。工作量的评估的一个很重要要素是原来业务系统本身在处理平台依赖上的成熟度（依赖的多少和程度），这个工作量不再这里评估，尽管这个可能是导致工作量最重要的因素。
上表的难易程度只是近似的估算，没有对应的数据支撑，侧重于服务发布方式之间进行调整适配的工作量，更细粒度来讲，就是数据类型支持方面改造的工作量，仅供参考。正如上面分析的，业务改造的工作量更多的来源于原来业务系统本身的耦合程度。
2.3 对开发者的建议
在上面的难易度评估矩阵中，有一个协议gRPC需要特别提到一下。在所有的框架中，将代码切换到gRPC，都是最难的，但是将gRPC切换为其他框架，都是最容易的。一般的，如果一个框架满足如下特征：
1. 更加贴近业务代码的书写形式，比如采用RPC的方式对外发布服务；
2. 更多的跨语言方面约束；
3. 更少的平台API
那么其他框架改造为这个框架会更加难，但是这个框架改造为其他框架更加容易。因为1，在切换为其他框架的时候，只需要将接口以其他框架的形式包装一次，不涉及任何代码修改；因为2，可以适配更多的接口约束和更多的序列化方式，支持的框架更多；因为3，不涉及平台API的整改和对等切换。
很多业务都会考虑对于平台绑定的问题，特别是那种需要长期发展的业务。因为平台技术日新月异，变化的场景驱动业务采用更加先进的架构技术改善业务的运行状况，比如JAVA技术的从Osgi到J2EE到WEB到微服务架构。那么业务如何去适应这个变化了？上面3个特性实际上给了一个指引。另外就是还需要加上：
4. 尽可能符合标准协议的约束。
这条规则和构造WEB应用时该选用那些功能一样的。在书写HTML的时候，尽可能的遵循HTML4、HTML5规范，能够让网站在更多的浏览器上精彩的呈现。
更好演进的另外一个方面，就是把使用的技术限制在能够跨平台的范围内。这块无疑会增加开发者的成本，需要学习更多的规范和培养更好的编码技能。有些业务场景，还必须使用平台特性去解决。这些复杂性都不会让我们的代码完美，总是在一个权衡和妥协中发展。
下面提供了一个代码设计方面的模式，这种模式解决了发布形式的切换问题。业务代码按照这样的模式进行组织，并且在接口定义上尽可能考虑跨语言数据结构（主要指数据类型），那么这种业务代码在配套平台升级的时候，将会是最快速的。
逻辑结构：
代码示例：
在CSE给的[项目例子中]( https://github.com/apache/servicecomb-samples/tree/master/porter_lightweight)， 采用Spring进行了接口和实现分离的代码结构，这种代码结构实现的代码，迁移到CSE、Dubbo、Spring Cloud、gRPC等框架的时候，只需要修改Endpoint层的定义，而不需要修改任何实现逻辑。因此建议开发者按照这种代码风格组织代码，从而更加方便的切换框架。但是开发者需要注意，历史遗留系统很多不是按照这个方式组织代码的，那么历史遗留代码的重构的工作量，很大程度上决定了改造的工作量。
5. 尽可能选择开源的微服务开发SDK。
选择开源的SDK的好处是即使商业公司不提供SDK的开发支持，或者成本很高的时候，可以通过开源社区或者自行编译源码，去适配其他的中间件，从而让业务能够在不同的技术组合下运行起来。
2.4 总结
结合上面的观点，所有框架不会在各种方面都是完美的，CSE SDK在灵活性方面的折中做得非常的出色，CSE的SDK也通过ServiceComb项目进行了开源，并且代码是同源的。CSE通过提供业务代码的书写习惯支持大大减少了切换为CSE的工作量，同时后续如果将CSE迁移到其他框架，相对来讲也是非常容易的。可以通过ServiceComb的开放性设计，了解CSE SDK的设计思路。同时客户也应该认识到，应用系统进行良好的抽象设计，能够更好的适配不同的平台和开发框架，客户应该在平台能够提供的价值服务和绑定关系方面做出权衡取舍，以最优的方式选择适当的平台服务。单纯从技术上来讲，平台绑定的担忧很多时候是应用系统本身架构和代码质量的一个侧面反映。
作者：liubao68