Recommended reading:
1. Domain-Driven Design
Development of micro-service primary challenge:
The large, complex applications split into small, autonomous, independently deployable modules.
If you do not split properly, the result is a pile of paste, has the disadvantage of the monolithic structure, and complexity of the micro-structure of the service, you can call distributed monomer .
Fortunately, Eric Evans for the field-driven design made a number of best practices and experience skills, there are three core thinking:
- To the development team and business units work closely with experts in the field of business.
- Architects, developers, domain experts should first make a strategic design: to find out border context, the core domains, subdomains, context mapping relationship.
- Architects, developers design a strategy according comb core building blocks: the entity, the value of the object, polymerization and the like.
The system is divided into a large core domains, subdomains, then the core domains, subdomains mapped to the micro-service, so that we can get an ideal micro loosely coupled service system.
2. Each serving a micro database
Micro service module design Well, here is an important question is how to deal with the database, each micro services are shared database?
If shared, will result in tight coupling between the micro services, contrary to the principle of micro loosely coupled services. A small change in the database will need to modify each team synchronization.
If each service has its own micro database, the data exchange between the micro services will be very difficult, like opening a Pandora's Box, we ran a bunch of questions, such as management services across multiple services.
Therefore, many people advocate a shared database.
However, micro-services is a continuous, long-term software development, each micro service should have its own database.
3. Micro distal
Many back-end developers despise the front, considered to be too simple.
Most architects are also out of the back-end, front-end is not enough emphasis in the architecture design.
Lead to the status quo is, the back-end modular doing well, and the front end or a whole lump.
Front-end and back-end single monomer structure has the same problem, the front end also need modernizing.
Now the web technology is simple, powerful, such as web components, Angular / React.
4. Continuous Delivery
Each micro-services can be deployed independently, it is one of the core strengths of the micro-services architecture.
比如你的系统包含 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
