服务组件化：

    在微服务架构中，需要我们对服务进行组件化分解，服务是一种进程外的组件，它通过HTTP等通信协议进行协作，而不是像传统组件那样镶入式的方式协同工作，每一个服务都独立开发、部署、可以有效避免一个服务的修改引起整个系统的重新部署。

按业务组织团队：

    在实施微服务架构时，需要采用不同的团队分割方法。由于每一个服务都是针对特定的业务的宽栈或者全栈实现的，纪要负责数据的持久化存储，又要负责用户接口定义等各种跨专业领域的职能。因此面对大型项目的时候，对于微服务团队的拆分更加建议按业务线的方法进行拆分，一方面可以有效的减少服务内部修改所产生的内耗，另一方面，团队边界可以变得更为清晰。

 做产品的态度：

    在微服务架构团队中，每个小团队都应该以做产品的方式，，对其整个生命周期负责，而不是像传统项目开发那样，交付给测试，运维为目标

智能端点和哑管道：

    由于各个服务不在一个进程中，组件间的通信模式发生了改变，原本进程内的方法调用变成了RPC方式的调用，会导致微服务之间产生烦琐的通信，使得系统表现更为糟糕，所以我们需要更粗粒度的通信协议：

    在微服务架构中，通常会使用一下两种服务调用方法：

    （1）使用HTTP的RESTful API或者轻量级的消息发送协议，实现消息传递与服务调用的处触发。

      (2) 通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的中间体。

        在极度强调性能的情况下，还有可能会使用二进制的消息发送协议，例如protobuf

去中心化治理：

    在整个微服务架构，通过采用轻量级的契约定义接口，使得我们队服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的各个组件就能针对不同的业务特点选择不同的技术平台。

去中心化管理数据：

    在实施微服务架构时，希望每一个服务自己来管理其数据库，这就是数据管理的去中心化，虽然数据管理的去中心化让数据管理更加细致化，让数据存储和性能达到最优，但是不同的数据库实例，数据一致性也成了微服务架构中亟待解决的问题之一，分布式事务本身实现的难度就非常大，所以在微服务架构中，我们更强调各服务之间进行”无事务“的调用，而对数据一致性，只要求数据在最后的处理状态是一致的即可。

基础设施自动化：

    在微服务架构中，务必从一开始就构建起”持续交付“平台来支撑整个实施过程；    

通错设计：

    在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计考虑的，通常我们都希望在每个服务中实现监控和日志记录的组件。比如：服务状态、断路器状态、吞吐量、网络延迟等关键数据的仪表盘等。