• 什么样的服务是好服务

　　松耦合：能够独立修改及部署单个服务而不需要修改系统的其它部分。

　　高内聚：把相关的行为聚集在一起，把不相关的行为放在别处。这样如果要改变某个行为时，就能够只在一个地方进行修改，然后就可以尽快发布了。

 

• 界限上下文

　　任何一个给定的领域都包含多个界限上下文，每个界限上下文中的东西分成两部分，一部分不需要与外部通信，另一部分则需要。每个上下文都有明确的接口，该接口决定了它会暴露哪些模型给其他的上下文。

 

• 留心过多的约定

　　有些工具会为了短期利益而牺牲长期利益，为了让你一开始启动得足够快，它们会使用一些不好的实践。比如有些框架可以很容易地表示数据库对象，并把它们反序列化成进城内的对象，然后直接暴露给外部。这种方式内在的耦合性所带来的痛苦会远远大于一开始就消除概念之间的耦合所需要的代价。

　　我们很容易把存储的数据直接暴露给消费者，那么如何避免这个问题呢？一个很有效的模式是先设计外部接口，等到外部接口稳定知道再实现微服务内部的数据持久化。在此期间，简单地将实体持久化道本地磁盘的文件上，当然这并非长久之计。这样做可以保证服务的接口是由消费者的需求驱动出来的，从而避免数据存储方式对外部接口的影响。其缺点是推迟了数据存储部分的集成。

• 基于HTTP的REST的缺点

　　从易用性来讲，基于HTTP的REST无法生成客户端的桩代码，而RPC可以。

　　有些Web框架无法很好地支持所有的HTTP动词。

　　性能上也可能会遇到问题，基于HTTP的REST支持不同的格式，如JSON或二进制，所有负载相对SOAP来说更加紧凑，在要求低延迟的场景下，每个HTTP请求的封装开销可能是个问题。所以，对于服务和服务之间的通信来说，如果低延迟或者较小的消息尺寸对你来说很重要的话，那么一般来讲HTTP不是一个好方法。

　　有些RPC的实现支持高级的序列化和反序列化机制，然而对于REST而言，这部分工作就要自己做了。