微服务思考(02)：微服务实施前有哪些问题？
前言
前一篇文章简单分析了微服务的好处，以及会带来的问题。
遇到问题并不可怕，可怕的是我们不去面对它，不去想办法解决它，逃避问题是不可能有任何进步。所以积极想办法应对问题并解决问题，才能不断的进步。
前面讲了，微服务一般都是由单体演进而来，很少有业务从0就开始进行微服务开发。如果能从0就开始用微服务开发，确实是一件很好的事情，前提是你确实考虑清楚了用微服务开发适合当前的业务以及业务的发展需求。
那么问题来了，企业什么时候引入微服务开发呢？
企业什么时候引入微服务开发？
引入原因：
单体应用无法满足业务增长的需求，业务的交付、业务的可靠性、稳定性要求，随着时间推移问题会越来越多。– 也就是前面遇到的一些问题
不过也有人，不是从本公司业务发展，开发成本，开发效率来考虑问题，而是什么开发大会上看到很多公司微服务的演讲，或者听说很多公司在用微服务，从这些方面来考虑，也就是随大流，这种思考方式显然不是正确思考方式。不要为了微服务而微服务。采用微服务收益一定要大于单体应用，要能解决遇到的问题。
从单体架构升级到微服务架构，肯定希望提高研发效率，缩短工期，加快产品交付速度。
那他们在具体生产效率上有什么区别？
根据马丁·福勒（Martin Fowler）的这篇文章，揭示了生产率和复杂度的关系。
在复杂度较小时，单体应用的生产率更高，微服务架构反而降低了生产率。但是，当复杂度到了一定规模，无论采用单体应用还是微服务架构，都会降低系统的生产率。区别是：单体应用生产率开始急剧下降，而微服务架构则能缓解生产率下降的程度。如下图：
x 轴是系统复杂度，y 轴是开发的生产力
- 绿色表示单体应用
- 蓝色表示微服务架构
单体应用和微服务有一个相交的点，这个点是单体应用生产率急剧下降，微服务平缓下降的交叉点，他们的生产效率开始出现不同。
这个点就是把单体应用切换到微服务的时间点。
但问题是，这个时间点，文章并没有具体说明什么时候会出现，怎么衡量这个时间点。
所以只能各个公司具体问题具体分析，技术领导者要考虑判断这个时间点。这也是考虑技术领导力的时候。不过有些考虑要素可以参考：
- 业务交付
- 业务需求开发是否经常延迟
- 产品交付是否能跟上业务发展
- 研发质量
- 代码是否因为修改而经常出现bug
- 代码臃肿庞大
- 技术力量
- 有技术，有意愿
- 团队人数
等等一些考虑因素，在加上前一篇单体应用出现的一些问题。
在考虑清楚之后，决定引入微服务，那么，又会遇到什么问题？
组织架构如何变化？
康威定律
康威定律 (康威法则 , Conway’s Law) 是马尔文·康威1967年提出的：
设计系统的架构受制于产生这些设计的组织的沟通结构。
康威定律告诉我们，如果我们实施了微服务，那么组织架构的变动也要跟着实施微服务架构而做出相应的调整。这样才有可能适应微服务的发展。
单体架构和微服务架构
先看看传统单体架构和微服务架构，如下图：
左半部分的单体架构图：
单体应用将所有功能放到一个进程中
扩展：通过将整个应用复制到多态服务器实现扩展
右半部分的微服务架构图：
微服务架构将功能分离，放到多个不同的进程中
扩展：通过将不同的服务分布于不同的服务器上，并按需要复制方式进行扩展
组织架构
-
单体应用的组织架构：
它是一个整体式的应用团队，每个团队按照职能来进行划分（图片左半部分），比如：UI团队，中间件团队，DBA团队。
不同职能的人属于不同的团队。做项目的时候就从不同职能部门选出一些人来负责项目。这样的组织架构有一个问题就是：跨职能部门沟通协调问题。这种团队组织形式不能适应微服务架构的特点。
-
微服务应用组织架构
微服务架构特点：每个微服务是独立的，团队可以独立开发，独立测试，独立部署，服务是自治的。相应的团队组成人员也有产品，技术，测试，团队成员在自己内部就可以完整的进行微服务各种功能开发。
这就要打破原先传统的那种按职能划分的组织团队形式，而要把不同职能的人组织在一个团队内，组成一个跨职能的产品组织架构。这样才能把一个微服务功能架构、设计、开发、测试、部署、上线运行，在一个组织内部完成，从而形成完整的业务开发闭环。
团队组织的变化
一图胜千言：
图片来自：https://insights.thoughtworks.cn/management-of-microservices-team/
原先那种职能型的团队，变成了跨职能的小团队，这种团队和微服务架构对齐。
说明： 以上图片侵删，请联系主页邮箱！