服务组件化
组件，是一个可以独立更换和升级的单元。在微服务中，我们需要对服务进行组件化分解。具体而言，我们需要将项目按照不同业务划分了多个服务，服务之间通过HTTP等通讯协议进行协作，彼此独立。每个服务都独立开发、部署、升级。
按业务组织团队
每个微服务都是针对特定业务的宽栈或是全栈实现，既要负责数据的持久化存储，又要负责用户接口的定义。所以需要按照业务需求，成立一个全栈型小团队负责一个服务的开发。
做产品的态度
每一个小团队，都应将自己的服务作为一个产品进行开发，对其整个生命周期负责。
智能端点与哑通道
传统的RPC调用，会给微服务的协作带来繁琐的通信，使得系统变现糟糕。在微服务中，我们需要粗粒度的通信协议：
- 基于HTTP的Restful接口
- 轻量级的消息发送协议（自定义）
- 基于消息队列
在这里，我们将面对高效性与易读性的平衡。对于大部分的微服务，并不强调性能，可采用restful接口的形式；面对重量级服务的调用，可以引入消息队列中间件，帮助服务之间进行异步协作；对于高性能、高实时性的要求，需要我们自定义一些消息协议，例如基于TCP和protobuf。
去中心化的处理
每个服务都是相对独立的，可以用不同的技术方案实现，无需采用统一的技术架构——只要定义并遵守协作协议。
去中心化管理数据
由于服务之间业务的相对独立，最好是让每个服务都拥有并管理自己的数据库，优化数据存储和性能。但是服务之间是有联系的，数据一致性也成了微服务架构中急需解决的问题之一。（分布式事务）
基础设施自动化
- 自动化测试
- 自动化部署
容错设计
在分布式架构中，单个服务崩溃是很常见的事。所以，快速检测出故障并尽可能地自动回复服务是必须被设计和考虑的。
演进式设计
微服务的架构设计，应当是逐步推进的。先核心后边缘、先稳定后多变。必要时可以先将多个业务实现为单个服务，在后期业务稳定后再进行重构。
个人总结
对一个项目进行微服务设计，首先需要根据业务划分为多个相对独立的服务（组件化），服务之间通过粗粒度的通信协议进行协作。按照业务成立小而全的团队进行开发，团队以“产品”的态度对待服务，对其整个生命周期负责。服务不需要采用统一的技术平台，只要制定好协作协议，可以按照业务需求采用适当的服务架构和技术。在尽量避免数据一致性问题的情况下，服务应尽可能独立管理数据。微服务体系整体应考虑容错设计，避免单个服务崩溃影响整体业务。同时，应完善自动化测试和自动化部署，减轻服务碎片化带来的运维压力。完美的微服务架构的设计，是在不断优化、重构中演进生成的。
参考
- microservices
- 《Spring Cloud微服务实战》
