体系化认识微服务之二：如何实施微服务架构

微服务作为一种架构风格，其主要特点是由很多小的服务组成，且每个服务都是可独立部署的，任何一个服务的升级部署都不会影响其他的服务。那么在企业中如何实施微服务这种架构呢？

按业务组织团队

康威法则：设计系统的组织，其产生的架构设计等价于族之间的沟通架构。

在以往传统的软件架构中，所有的功能都是在一个单体系统中完成的，每个团队都可以在上面修改代码，开发测试部署也比较方面。但是随着业务的扩展和功能的不断迭代，单体系统越来越难以维护，故障率不断上升。

康威法则其实解决的是多团队并行开发的痛点，不同的业务有不同的团队维护，每个团队维护他们自己的服务，团队的边界会更加清晰，开发效率也会大幅提升。

按业务组织团队带来的结果是，每个需求的开发都是按产品进行交付的。也就是说需求的开发是跨团队的，这个团队会有各个职能部门的同学，比如产品经理、工程师、测试、DBA、运维等角色。

微服务产品交付流程如下：

第一阶段：产品经理会组织需求评审，明确这个产品要做什么，如果需求比较会先进行可能性评审

第二阶段：由于最终是以产品进行交付的，在实际开发中会明确一个项目负责人，他会给出这个产品的技术文档，明确每个人要做什么以及怎么做的问题

第三阶段：给出方案后，不同职能部门的人员各自进行开发

第四阶段：开发完毕后，把产品（一般会有多个项目，每个项目不同的分支）交付给测试人员进行测试

第五阶段：测试完后，把产品交付给运维进行构建部署

第六阶段：运维构建部署后，开发人员发布上线

第七阶段：线上观察反馈，验证产品质量。如果有问题，产品重新提需求，进入一个闭环

服务拆分

单体应用要改成微服务架构的首要问题是，有哪些服务或者模块是要拆分出去，并且哪些服务要归属到各个业务团队；这些众多的服务要怎么拆分。

哪些服务要拆分

所有的服务按照业务维度可以分为两种：业务相关和业务无关的服务。

业务无关的服务包括存储基础服务、公共服务。存储基础服务又可以分为数据库、缓存。公共服务分为短信服务、邮件服务、地图服务等。

业务相关的包括领域服务、存储领域服务。这里存储服务包括业务无关的服务，比如赠增删改查，又包括特定条件查询服务等和业务相关的存储服务。

服务怎么拆分

将需要拆分的服务梳理后还有一个问题要解决，这些服务怎么拆分。我们按照从底层到上层的方法拆分不同的服务，从底层到上层分别为：数据层服务、业务服务。

数据层服务是与业务无关的服务，把底层访问数据的细节以服务的方式提供出去，例如我们拆分出了经纬度服务、地图服务业务、城市服务等底层数据服务。业务服务是核心服务，把数据层服务+业务逻辑组合起来构成业务服务，业务服务把底层访问数据层的服务屏蔽起来，调用方不用关心具体细节，例如我们把订单和商家分为两个业务服务，按照业务的领域可以分为更多的业务服务。