推荐阅读：
1. 领域驱动设计
微服务开发的首要挑战：
把大的、复杂的应用拆分为小的、自治的、可独立部署的模块。
如果没有正确的拆分，那么结果就是一堆浆糊，有着单体结构的缺点，和微服务结构的复杂度，可以称之为分布式单体。
幸运的是，Eric Evans 为领域驱动设计提出了大量的最佳实践和经验技巧，有3个核心思维：
- 开发团队要和业务部门、业务领域专家紧密合作。
- 架构师、开发人员、领域专家应该先做出战略设计：找出边界上下文、核心域、子域、上下文映射关系。
- 架构师、开发人员根据战略设计梳理出一套核心构造块：实体、值对象、聚合等等。
把一个大型系统划分为核心域、子域，再把核心域、子域映射为微服务，这样我们就可以得到一个理想的松耦合微服务体系。
2. 每个微服务一个数据库
微服务模块结构设计好了，下面一个重要问题就是怎么处理数据库，各个微服务是否共享数据库呢？
如果共享，将导致微服务之间紧耦合，违背了微服务的松耦合原则。数据库中一个小小的变动就需要各个团队同步修改。
如果每个微服务都有自己的数据库，那么微服务之间的数据交换将非常麻烦，就像打开了潘多拉魔盒，跑出一堆问题，例如在多个服务中管理事务。
所以，很多人主张共享数据库。
但是，微服务是持续的、长期的软件开发，每个微服务应该有其自己的数据库。
3. 微前端
很多后端开发者轻视前端，认为太简单。
大多数架构师也是后端出来的，在架构设计中对前端不够重视。
导致现状就是，后端模块化做的很好，而前端还是一整坨。
前端单体结构和后端单体有一样的问题，所以前端也需要进行现代化的改造。
现在的 web 技术简单、强大，例如 web 组件、Angular/React。
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
来源：oschina
链接：https://my.oschina.net/u/3173102/blog/3157508