自动化部署CI/CD和微服务

如上图，使用微服务开发时的整个流程。
在上面流程中，开发人员只需要将代码提交到相应的分支，环境会自动对代码做测试并生成相应的镜像，并再根据新的镜像生成新的服务

微服务可以理解为项目的模块，运行在docker（主流），而管理这些docker，用k8s（主流）

为什么要用到微服务？
在传统的架构中，应用如果频繁升级，开发团队会非常痛苦。
因为企业系统经过多年发展，往往会非常庞大，复杂性太高，要改变任何1个小地方，都要重新部署整个应用
另外多年的系统建设过程中往往会用到不同的技术栈，统一的管理和运维也变得很复杂，随着这些问题越来越严重，企业向微服务转型的需求就越来越强烈。

容器技术的成熟为微服务落地提供了基础，轻量化的容器时微服务运行的环境
微服务只有在容器技术下，再结合高效的编排管理工具，才能使 持续集成，快速交付 变得可能

什么是微服务？
使用一套小服务来开发单个应用的方式，每个服务运行在 独立的进程 里，一般采用 轻量级的通讯 机制互联，并且它们可以通过 自动化 的方式部署。

单一职责：比如订单和支付可以作为一个服务，登录和注册可以作为1个服务，无关的功能则抽离出去做另外的服务
轻量级通信：平台无关，语言无关，如http协议，不过实际应用中一般使用rpc
隔离性：每个微服务运行在自己的进程中，不会相互干扰
有自己的数据：有自己的存储系统
技术多样性：可以由开发人员选择最适合的技术去实现业务需求，只要最后能提供 对应功能的api接口 即可

互联网发展到今天的特征是需求变化快，用户数量变化快，因此需求app 能更快速的迭代
敏捷开发：用最小的代价做最快的迭代，看到有用的反馈，说白了就是频繁的开发，修改，上线

下图是单体架构情况下的架构图：

改成微服务架构图如下：

上图只是粗略，实际并不是每个微服务都能提供 restful-api

比如登陆注册的qps 少，用户信息的qps 多，那就可以启动2个登陆注册服务，启动5个用户信息服务，在扩容缩容上非常方便
敏捷新：微服务一般功能都比较单一，对用户来说容易理解调用，另外要修改某个功能时，很容易定位到那个功能且微服务是较简单的，修改起来也容易

额外的工作：如何拆分微服务，这是大问题，可以查询 领域驱动设计。拆分微服务时要尽量保证对微服务的连表操作在同一个微服务里面，但也很难保证不产生依赖，一旦出现就会给数据一致性带来挑战
沟通成本：可能要修改的微服务不是自己负责的，这就要推动其他人或其他组织干活，如果这种修改比较多，沟通成本会比较大