刚经历了一次将公司原有系统搞成微服务架构，低估了转换带来的问题，理想很丰满，现实很残酷，途中遇到了许多问题，在这里记录分享一下。

为什么使用微服务架构

微服务是现在最为流行的软件设计架构，基本上所有公司都用微服务架构。微服务架构是指将一个大型的单体系统按职责范围切分成多个小的服务开发与部署，各服务通过轻量级的通信协议连接到一起。这种设计的好处在于，每个服务都是独立部署、负责的功能也不相同，能够很容易的根据实际需求单独调整某几个服务的服务能力（增减服务实例），也能实现服务复用，更灵活以及由弹性。

微服务在落地中遇到的问题

• 对原有系统的拆分，导致需要部署维护的实例大幅增加
• 日志分散在多个服务多个实例当中，一旦遇到问题要查询日志是件很困难的事情
• 服务边界的确定与维护

怎么解决的

• 持续集成部署，我们是使用gitlab作为代码仓库，在gitlab上配置了ci/cd，当我们指定的分支代码发生变化时，会自动执行我们的ci/cd脚本，将项目打包成docker镜像推到我们的harbor镜像仓库，然后通过rancher编排更新容器。
• 使用spring cloud sleuth，为日志加上关联ID，并且通过Elasticsearch+Fluentd+kibana将多个服务实例的日志聚合起来，可以在kibana上可视化的操作查询日志。
• 对于基础的服务，比如支付服务、账号服务、短信服务我认为应该要坚决的拒绝在里面处理其他业务相关的内容，我们可以接受并原样返回一些其他业务参数，但这些参数不应导致基础服务处理结果的不同。只有这样这些基础服务才能很好的被复用。

总结

微服务架构带来的是一系列用于支持微服务的设施，在做微服务改造前因仔细评估团队以及公司的能力是否满足，以及系统是否有改造的必要。