我也来谈微服务（二）

上一篇介绍了微服务基本概念，现在深入说一下。

服务拆分

微服务中的每个服务单元都是粒度很小、功能单一的，这个小自然是相对的，其设计思想是：与其搞一个大而全的的服务体，我们更倾向于小一些的单一服务。那怎么样的服务粒度是适合的呢？当我们在思考服务的边界问题时，需要平衡好内聚和耦合的关系，高内聚低耦合，相比大家已经相当了解了。一方面为了加强内聚可能将某些服务聚合到一起，另一方面为了解耦，需要对某些服务进更细粒度的拆分，事实上在使用为服务的的时候这个过程可能是往返的。最佳的实践应该是：第一，从领域驱动设计的方式思考服务边界，从业务角度思考服务的边界。想想服务所提供的产品、服务是什么。从这个角度想怎样才算是一个合理的服务边界；第二，想想服务之间的通信模式，如果拆分成多个服务，不同的服务之间怎样合作才能实现一个特殊的业务产出，特别是犹豫不决时候，想想拆开之后可能产生的各种通信以及通信失败的的情形；第三，从数据结构，大家不愿意花费太多的精力想怎么保护数据的问题，也不会纠结太多最终一致性产生的影响，我们想的不再是围绕数据库建一堆服务而是每个服务由自己的持久化存储，简单来说可能是每个无法都有自己的一套数据库，当然服务之前数据的一致性还是要保证的；第四，这个可能是大家忽视的，就是构建的独立性，譬如你是一个maven的项目，你的每个服务要能保证单独构建，这个和以后的CI/CD紧密相关。

服务扩展

微服务的另一个特点是，这些服务是按照业务能力构建的。之前我们经常会陷入一个陷进：从系统的角度去思考问题，而不是从业务角度去思考。现在我们不仅要从系统的角度去思考更要从业务的角度。微服务的中的服务体可以单独部署的，也就是说只要没有修改接口协议，在修改某一个服务个体的时候完全没有必要理会其它服务体。在微服务中只有很少一部分需要集中管理，而由于各个服务之间是相互独立的，因此我们可以在不同的服务体内使用不同的技术栈，只要遵循统一的接口规范即可，如http rest接口。微服务中每个服务多可以单独扩展，也就是说在服务的需求量猛增的时候，我们需要快速的扩展服务即可，这个可用通过容器技术迅速扩展，在扩展的过程中，服务的调用者不需要关心，那么对于服务的监控显得尤为重要，不仅需要监控服务压力（需求量），为扩展提供依据，还有监控服务的健康状态，这个大家可能不太容易理解，因为以前单体式的服务个数少，不太关心这个问题，现在微服务过后，服务的个数会猛增，服务出现挂掉的情况也会增加，所以这部分的监控也是必须的。

服务构建、部署和交付

服务的单元变多了，虽然单个服务简单了，但其实整个系统却是变得复杂了，因此我们真的需要一套CI/CD的系统，自动构建、自动部署和自动的交付。这首先是自动构建，就是开发人员编写完代码提交的代码仓库后CI/CD这套系统就可以对代码进行编译打包，并且可以把编译过后的服务部署启动，这样可以进行后续测试等工作，当验证功能ok以后，就需要自动的完成服务的升级和上线。微服务相比传统架构，增加了运维的负担。有更多的东西要部署，更多的服务要监控，更多的数据库要备份。因此如果不能严格执行CI/CD这套流程的话，只是把现有单体服务微服务改造的确会带来更多的麻烦。在程序出错的时候要赶紧进行调试，但如果你连代码是哪个版本都不知道，无从查起。
最后还要补充一下，说到微服务必须还要解释情况，什么是有状态服务，什么是无状态服务，服务所维护的与客户交互活动的信息称为状态信息。不保存任何状态信息的服务器称为无状态服务，反之则称为有状态服务，简单来说就是服务一次服务的请求返回的结果只依赖请求参数和数据库数据，自身没有包含状态数据。譬如一个求和的接口就是一个无状态的。