1.5 为实施微服务架构做好准备

微服务架构并不是一种新技术，它只是一种全新的设计理念，所以，为了能够更好地实施微服务架构设计，我们必须做好前期准备，从思想观念、团队管理和自动化基础设施上进行相应的变革。

1.5.1 思想观念

在进入微服务领域之前，必须从做项目的观念转变成做产品的观念。如果是一个软件项目，在完成了业务需求的设计之后，最终交付使用，其项目开发的生命周期就宣告结束。而做产品则完全不一样，只要产品成型上线，产品有存在的价值，开发就永远没有终结。随着产品的更新换代，其中的应用程序和组件也要跟着不断地进行更新和迭代。

微服务架构的渐进式设计的特点，就是一种做产品的观念的真实体现。一方面，一个产品的最初成型设计，由于种种原因并不可能把所有功能都考虑得很周到，这需要一定的时间进行慢慢的磨合与创新。另一方面，市场总是处于变化之中，所以产品的业务功能也会随着时间的推移而发生一定的变化。

做产品的观念将贯穿于一个系统平台的整个生命周期之中，并随着平台的发展和演化，最终将产品打造成一个充满活力的生态体系。

1.5.2 团队管理

传统的团队管理，是按技术进行分组的。在一个开发团队中，可能有UI设计组、前端开发组、后端开发组、测试组和运维组等。

在微服务架构实施中，开发时是按业务功能进行划分的，所以对团队的管理，最好也以业务进行分组，将产品设计、前端开发、后端开发、测试和运维等人员围绕业务功能分配在同一组中，这样不但可以增强团队的凝聚力，还可以避免将大量的时间浪费在不同组别的沟通和工作协调上。

在实际操作中，因为前端开发和运维管理的消耗不是很大，所以对这两部分人员可以进行机动的调整。但这种调整最好是在业务相近的领域中进行的，并保持一定的连贯性，即原来由谁负责的工作，在更新和维护时还是由他来负责。

为了减少资源的浪费和增加每个人员的工作饱和度，一个业务小组往往并不只负责一个微服务，有可能负责两三个微服务的开发，这主要由微服务划分的粗细粒度来定。

1.5.3 自动化基础设施

从整体式架构向微服务架构转变之后，项目数量会增加，迭代的周期会变短，对测试和运维人员也会提出更高的要求，并且其工作量会越来越大，所以单纯依靠人力来完成这两部分的工作是远远不够的，这就要求必须有自动化基础设施的支持，来完成自动集成、自动测试，以及持续交付、持续部署的工作。

一个原来由几个项目支撑起来的应用平台，在使用微服务架构进行拆分之后，可能会变成几十个项目，甚至上百个项目。如果还像原来那样分配测试和运维工作，则势必要增加更多的人员。

在服务器资源的使用上，也会相应的有所增加。因为每个微服务应用所占用的资源并不是很大，所以可以在原来的服务器中使用虚拟机技术扩展服务器群组。对于微服务的部署，我们将主要以Docker容器为主导，使用虚拟化技术实施自动化建设，这样可以非常自由地将微服务分散部署在分布式环境之中。而对于中小型企业来说，更好的实施方案是使用云计算服务商提供的资源，这样能更有效地利用服务器的资源。