1. 好的微服务架构都具备什么特点
应该具备两个核心特点，松耦合、高内聚。这两个核心特点应该是一种仅次于SOA概念层级的概念，不遵循（或不具备）这两个核心特点的话，讨论更多的细节都没有什么意义了，更不可能建设出一个优秀的微服务架构实践了。
2. 松耦合
如果做到了服务之间的松耦合，那么修改A服务就不需要修改B服务。使用微服务最重要的一点是，能够独立修改及部署单个服务而不需要修改系统的其他部分，这是非常重要的。
一个松耦合的服务，应该尽可能地少知道与之协作的那些服务的信息，一个小的实践就是接口需要的参数尽可能的少。
3. 高内聚
我们希望把相关的行为聚集在一起，把不相关的行为放在别处。为什么？
因为如果要改变某个行为的话，最好能够只在一个地方进行修改，然后就可以快速的发布。如果同时需要修改多个服务，就得同时发布多个微服务才能交付这个功能。这样的结果就是修改起来慢，部署风险高，上线成本高，这几点都是应当尽力避免的。
所以，找到问题域的边界就可以确保相关的行为能放在同一个地方(服务)，并且他们会和其他边界以尽量松耦合的形式进行通信。
4. 限界上下文
这一概念是在Eric Evans的《领域驱动设计》一书中提出的，Eric Evans认为任何一个给定的领域都包含多个限界上下文CTX，每个CTX中的东西分成两部分，一部分不需要与外界通信，另一部分则需要，一个CTX都有明确的接口，决定了哪些内容会暴露给其他的CTX。Eric Evans使用细胞膜比喻：“细胞之所以存在，是因为细胞定义了什么在细胞内，什么在细胞外，并且确定了什么物质可以通过细胞膜。”
例如一个公司包含一个仓库部门和财务部分，仓库部门负责发出的订单以及退回的产品，还有新到的库存，还需要保证铲车的正常运行等等。而财务部门负责的是公司的工资单和公司的账户，并且生成很多重要的报表。
这里就可以看到，仓库和财务部门可以看做是两个独立的CTX，它们有明确的对外接口（仓库的存货报告、退货报告，财务的工资单发布等），也有着只需要自己知道的一些细节（铲车、计算器...）。
财务部门不需要知道仓库的内部细节，只需要知道库存水平以便于更新账户，以及退回的产品是否到货以便于退款。这些都通过接口实现两个部门之间的通信。所以接口的定义非常重要。
当然，通过不断的发展，仓库的内部细节越来越多，也可以再划分出不同的CTX，比如库存CTX，设备维护CTX。这其中保持不变的核心概念是：当一个领域内部细节足够多（通常是划分了多个模块），这个时候就应该考虑拆分这个领域，提取出模块间需要共享的部分。
5. 模块和服务
在刚开始开发一个代码库时，我们最好通过模块的方式来减少不同内部领域之间的耦合，当我们发现这个代码库中的限界上下文后，就可以使用模块对其建模，模块内隐藏一些细节，共享/暴露一些细节。
这些模块边界就可以成为绝佳的微服务侯选。一般来说，微服务应该清晰的和限界上下文保持一致。熟练之后就可以省掉在单块系统中先使用模块这个步骤，而直接使用单独的服务。然而对于一个新系统而言，可以先使用一段时间的单块系统，因为如果服务之间的边界搞错了，后面修复的代价很大。所以最好能够等到系统稳定下来，再确定把哪些东西作为一个服务划分出去。
所以，服务边界和领域的限界上下文保持一致，就跨出了走向高内聚松耦合的微服务架构的第一步。
6. 过早的划分
作者提到的一个亲身经历，一开始就使用微服务的方式构建新系统，几个月之后发现现在系统的用例和之前想的有所不同，这些不同证明了之前的服务划分方式有问题，这导致了很多跨服务的修改，代价相当高，后来作者的团队又逐渐把这些服务合并成了一个单块系统，给到所有人时间去理解服务边界到底应该在哪，一年后，团队识别出了非常稳定的边界，才再据此拆分成了微服务架构。
所以作者强烈建议：
很多时候，将一个已有的代码库划分成微服务，要比从头开始构建微服务简单得多。
在我看来，这其实和过度设计是一个道理。
7. 逐步划分上下文
刚开始你会识别出一些粗粒度的限界上下文，而这个CTX可能又包含一些嵌套的限界上下文。举个例子，你可以把仓库分解为不同的部分：订单处理、库存管理、货物接收等。当考虑微服务边界时，首先考虑比较大的、粗粒度的那些上下文，然后当发现合适的缝隙后，再进一步划分出那些嵌套的上下文。
8. 小结
这篇文章总结了什么是好的服务，以及如何在问题空间中寻找能达到高内聚松耦合的接缝。限界上下文是寻找这些接缝的一个非常重要的工具，通过将微服务与这些边界相匹配，可以保证最终的系统能够得到微服务提供的所有好处。
到此我们也了解了进一步划分微服务的方法，后面的文档会深入讨论这个话题。
另外作者在小结时再次提到了Eric Evans的《领域驱动设计》一书，说到其中提到的概念对于寻找的明显的服务边界来说非常有用。作者还推荐了一本书，Vaughn Vernon的《实现领域驱动设计》，这本书能够帮助我们理解如何实践这些方法。
到目前为止文章提到的内容都比较宽泛偏理论，下一章开始，内容技术性会更强。