服务组件化
每个服务都独立开发、部署，可有效避免一个服务的修改引起整个系统的重新部署。
按业务组织团队
以往对团队的划分多是从技术层面，比如分为DBA团队，运维团队、后端团队、前端团队、设计师团队等。若继续按这种方式组织团队来实施微服务架构开发，当有一个服务出现问题，可能只是新增一个字段，就需要从数据存储开始一直到设计和前端，虽然大家修改都很小，但这会引起跨团队的时间消耗和预算审批。
做“产品”的态度
在实施微服务架构团队中，每个小团队都应该以做产品的方式，对其产品的整个生命周期负责。
智能端点与哑管道
单体引用中，组件间直接通过函数调用的方式进行交互协作。而在微服务架构中，由于服务不在一个进程中，组件间的通信模式发生了改变，若仅仅是将原本在进程中的方法调用改为RPC方式的调用，会导致微服务之间产生繁琐的通信，使得系统表现更为糟糕，所以需要更粗粒度的通信协议。
在微服务架构中，通常使用以下两种服务调用方式：
1）使用HTTP的RESTful API或轻量级的消息发送协议，实现消息传递与服务调用的触发。
2）通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的中间件。
去中心化治理
实施微服务时，通过采用轻量级的契约定义接口，使得我们对于服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的各个组件就能针对其不同的业务特点选择不同的技术平台。
去中心化管理数据
在实施微服务架构时，都希望让每一个服务来管理其自有的数据库，这就是数据管理的去中心化。在去中心化过程中，除了将原数据库中的存储内容拆分到新的同平台的其他数据库实例中之外，还可将一些具有特殊结构或业务特性的数据存储到一些其他技术的数据库实例中。
基础设施自动化
自动化测试、自动化部署
容错设计
在单体应用中，通常是一挂全挂；在微服务架构中，由于服务都运行在独立进程中，所以存在部分服务出现故障而其他服务正常运行的情况。所以，微服务架构中，快速检测出故障源并尽可能自动恢复服务是必须被设计和考虑的。
