推奨読書：
1.ドメイン駆動設計
マイクロサービスの主な課題の開発：
大規模、複雑なアプリケーションでは、小さな、自律的、独立してデプロイ可能なモジュールに分割します。
あなたが適切に分割されていない場合、結果はペースト状の山であるモノリシック構造の欠点、およびサービスのミクロ構造の複雑さを持っている、あなたが呼び出すことができ、分散性モノマーを。
幸いなことに、エリック・エヴァンスは、フィールド駆動設計のためのベストプラクティスと経験スキルの数を作った、3つのコアの考え方があります。
- 開発チームとビジネスユニットへのビジネスの分野の専門家と密接に連携。
- ボーダーコンテキストを見つけるために、コアドメイン、サブドメイン、コンテキストマッピング関係：アーキテクト、開発者、ドメインの専門家は、最初の戦略的な設計を行う必要があります。
- エンティティ、オブジェクト、重合などの値：設計者は、開発者は、櫛コアビルディングブロックによる戦略を設計します。
システムは、我々が理想マイクロ疎結合サービスシステムを得ることができるように、大きなコアドメイン、サブドメイン、次いでコアドメイン、マイクロサービスにマッピングされたサブドメインに分割されます。
2.各マイクロデータベースにサービスを提供します
マイクロサービスモジュール設計さて、ここで重要な問題は、データベースに対処する方法である、各マイクロサービスは、データベースを共有していますか？
共有する場合は、マイクロ疎結合のサービスの原則にタイトなマイクロサービスとの間のカップリング、逆になります。データベースの小さな変化は、各チームの同期を変更する必要があります。
各サービスは、独自のマイクロデータベースを持っている場合は、マイクロサービス間のデータ交換は、パンドラの箱を開けるように、非常に困難なことや、複数のサービス間での管理サービスなどの質問の束を走っただろう。
そのため、多くの人が共有データベースを提唱します。
しかし、マイクロサービスは継続的、長期的なソフトウェア開発で、各マイクロサービスは、独自のデータベースを持っている必要があります。
3.マイクロ遠位
多くのバックエンドの開発者は単純すぎると考えられ、フロントを、軽蔑します。
ほとんどの建築家は、バックエンドの外にもあり、フロントエンドは、アーキテクチャ設計に十分な強調ではありません。
現状維持につながるで、よくやってバックエンドのモジュラー、およびフロントエンドまたは全部しこり。
フロントエンドとバックエンド単一のモノマー構造は同じ問題を抱えている、フロントエンドはまた、近代化を必要としています。
今、ウェブ技術は、このようなWebコンポーネントとして、強力な、シンプルで、角度/反応します。
4.連続配信
各マイクロサービスは独立して展開することができ、それはマイクロサービスアーキテクチャの強みの一つです。
比如你的系统包含 100 个微服务，现在有一个需要更新，那么你可以只需要发布这一个，而另外 99 个不需要动。
这就需要 CI/CD 和 DevOps，如果没有这套自动化流程的话，就像拉着手刹开法拉利。
5. 可观察性
微服务架构简化了开发，但复杂了运维。
单体结构是非常便于监控的，但在微服务架构中，服务很多，而且通常是跑在容器中，对整个系统的监控就变得非常复杂。
需要把所有容器、机器中的日志聚合到一起。
幸运的是已经有成熟的解决方案，例如，使用 ELK/Splunk 处理日志，使用 Prometheus/App Dynamics 处理监控。
还有一个比较重要的方面：调用跟踪。
微服务间会产生级联调用，为了分析系统延迟，就需要测量每个服务的延迟，Zipkin/Jaeger 提供了这个能力。
6. 统一技术栈
微服务体系中，不同服务有不同的特性，例如有的服务是 CPU 密集型操作，使用 C++/Rust 比较合适；有的服务是做机器学习的，使用 Python 比较合适。
所以，可以使用不同的技术处理相应的需求，但是，一定要注意合理性，不要毫无根据的混合使用不同的技术。
想象一下，在一套系统中，有的微服务使用 Spring Boot + Kotlin+ React + MySQL，有的使用 JakartaEE + Java + Angular + PostgreSQL，有的使用 Scala + Play Framework + VueJS + Oracle。
这会不会让人很崩溃，太难维护了。
7. 异步通信
服务间的通信问题是微服务架构的重要挑战，比是否共享数据库那个问题还麻烦。
为了实现业务需求，需要多个微服务的协同工作，服务间需要进行数据交换，一个服务需要触发其他服务。
最简单的就是通过 REST 接口直接调用，但这种同步调用方式问题比较大。
例如 A -> B -> C -> D，这种多级调用主要的3个问题：
- 增加了系统延迟。
- 每个服务可能会故障，这就产生了级联性的错误。
- 服务间紧耦合。
最好是使用异步通信的方式，例如通过消息队列（如 kafka）、异步的 REST（ATOM）、CQRS。
8. 微服务优先
很多人认为新项目应该使用单体结构，这样起步快，比微服务简单，当发展大了之后再改造为微服务。
然而，这个改造是非常困难的，因为单体中模块的耦合度太高了。
而且产品成熟后，对在线可用性要求很高，那个时候再改造的话，一定会中断产品运行。
9. 基础设施优于类库
Netflix 早期开发微服务时，主要使用 java 来开发，Netflix 开发出了很多优秀的库，如 Hystrix, Zuul，很多公司都使用他们。
后来，包括 Netflix 在内的很多公司都发现 java 其实并不擅长微服务开发，例如 java 体积过于庞大。
Netflix 转向了 Polyglot，并停止了之前那些库的维护，这就让很多公司被动了。
所以，不要过度依赖特定语言的类库，可以使用更底层的基础框架，例如 Service Meshes。
10. 组织考虑
50 年前，Melvin Conway 发现公司的软件架构受限于其组织结构。
其实在现在，这个观点依然正确。
如果一个组织想使用微服务架构，那么就应该调整好团队的大小。
两个披萨饼原则：如果两个披萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了。
而且，团队成员应该是多元化的，有前端、后端、测试、运维。
只有高层领导者转变思维方式，微服务架构才有可能发挥作用。
翻译整理自：
https://towardsdatascience.com/effective-microservices-10-best-practices-c6e4ba0c6ee20
