微服务架构在项目实战中的思考和总结

        微服务架构的概念经过多年得发展和应用已被大家所熟知，终于有机会从0开始在实际的项目中采用微服务的思想进行设计和实现，以下是在本次事件中的一些心得体会。

1、什么是微服务

        微服务的概念这里不再赘述，只讲一下自己的理解：微服务是一种项目设计的思想，可以降低服务之间的耦合，方便程序的设计、开发和维护。在部署的时候可以采取容器化的技术进行自动化的发布。在分布式的应用中，可以降低单点故障，提高系统的健壮性。

        微服务适合在大型项目中进行应用，如果采用微服务的架构，相配套的部署、分布式事务、服务的治理等基础设施都要准备起来。

2、微服务的拆分原则

        微服务的拆分是其设计的精髓，微服务的主要难点也是在于服务的划分，对于划分的方式目前没有统一的标准，主要流行的一种思想就是领域驱动模型（DDD），我们在做项目的时候也是采取这种思想，首先进行领域建模，将项目进行细分，找到每个具体的实体，这一步是分，完成之后就是合，将有关联的业务实体聚合起来形成基础服务，在基础服务之上再建一层应用服务，应用服务是通过基础服务的组合，对外提供服务的。在基础服务之间尽量不要存在相互依赖，所有的依赖组合都要放在应用服务中完成，不然会造成服务难以维护的局面。

        一个项目具体要分多少个服务：不宜过多。首先可以根据业务进行划分，划分之后感觉服务的数量仍比较多，可以进行一些适当的合并。

3、接口设计

        基础服务一般是通过API的形式对应用层提供服务的，应用层往往采用Restfull风格的Api对外提供服务，在接口设计的时候一定要做到外部接口和基础服务api之间的定义要一致，主要是dto命名，属性名称，不一致的话会造成额外的工作量，而且还会感觉特别别扭，需要注意。

4、工时估算

        工时估算往往会是个坑，主要还是需要对业务进行全面的考虑，这个难度比较大，因为我们一般会把一个项目分给不同的人进行设计，这样会有一个问题，每个人设计的接口可能只能满足自己的需要，其他人要使用就会很难，需要修改或开发新的接口，这样很容易导致预估的时间不准确。可以从一下两个方面来考虑。

        首先是基础服务：基础服务尽可能提供细粒度的服务，但是也要考虑到一些实体之间的关联关系，如果在一个服务内，可以进行关联查询尽可能返回多的属性，不然就要在应用曾进行组合。

        其次就是应用层的服务：应用层服务的接口数量是比较确定的，难点是要理清每个服务需要哪些基础服务，并且还要考虑是否需要对基础服务返回的数据进行加工处理。

        通过以上两点进行工时估算，可以尽可能的做到准确，但是再设计之出需要多花费些时间，毕竟磨刀不误砍柴工。

5、总结

        这次项目经理了坎坎坷坷总算是达到了测试的要求，但是对于个人来说需要学习和总结的地方还很多，继续努力吧。总之小的项目要慎用微服务，大的项目在使用过程中一定要做全面的考虑。