一、前言
前一篇文章简略剖析了微服务的益处，以及会带来的问题。
遇到问题并不可怕，可怕的是咱们不去面对它，不去想方法解决它，回避问题是不可能有任何提高。所以踊跃想方法应答问题并解决问题，能力一直的提高。
后面讲了，微服务个别都是由单体演进而来，很少有业务从 0 就开始进行微服务开发。如果能从 0 就开始用微服务开发，的确是一件很好的事件，前提是你的确思考分明了用微服务开发适宜以后的业务以及业务的倒退需要。
那么问题来了，企业什么时候引入微服务呢？
二、企业什么时候引入微服务？
引入起因：
单体利用无奈满足业务增长的需要，业务的交付、业务的可靠性、稳定性要求，随着时间推移问题会越来越多。– 也就是后面遇到的一些问题
不过也有人，不是从本公司业务倒退，开发成本，开发效率来思考问题，而是什么开发大会上看到很多公司微服务的演讲，或者据说很多公司在用微服务，从这些方面来思考，也就是随大流，这种思考形式显然不是正确思考形式。不要为了微服务而微服务。采纳微服务收益肯定要大于单体利用，要能解决遇到的问题。
从单体架构降级到微服务架构，必定心愿进步研发效率，缩短工期，放慢产品交付速度。
那他们在具体生产效率上有什么区别？
依据马丁·福勒（Martin Fowler）的这篇文章，揭示了生产率和复杂度的关系。
在复杂度较小时，单体利用的生产率更高，微服务架构反而升高了生产率。然而，当复杂度到了肯定规模，无论采纳单体利用还是微服务架构，都会升高零碎的生产率。区别是：单体利用生产率开始急剧下降，而微服务架构则能缓解生产率降落的水平。如下图：
x 轴是零碎复杂度，y 轴是开发的生产力
- 绿色示意单体利用
- 蓝色示意微服务架构
单体利用和微服务有一个相交的点，这个点是单体利用生产率急剧下降，微服务平缓降落的交叉点，他们的生产效率开始呈现不同。
这个点就是把单体利用切换到微服务的工夫点。
但问题是，这个工夫点，文章并没有具体阐明什么时候会呈现，怎么掂量这个工夫点。
所以只能各个公司具体问题具体分析，技术领导者要思考判断这个工夫点。这也是思考技术领导力的时候。不过有些因素能够参考：
-
业务角度
- 业务需要开发是否常常提早
- 产品交付是否能跟上业务倒退
-
研发品质
- 代码是否因为批改而经常出现 bug
- 代码臃肿宏大
-
技术人员
- 有技术，有志愿
-
团队人数
等等一些思考因素，在加上前一篇单体利用呈现的一些问题。
在思考分明之后，决定引入微服务，那么，又会遇到什么问题？
三、组织架构如何变动？
康威定律
康威定律 (康威法令 , Conway’s Law) 是马尔文·康威 1967 年提出的：
设计零碎的架构受制于产生这些设计的组织的沟通构造。
康威定律通知咱们，如果咱们施行了微服务，那么组织架构的变动也要跟着施行微服务架构而做出相应的调整。这样才有可能适应微服务的倒退。
单体架构和微服务架构
先看看传统单体架构和微服务架构，如下图：
图片来自：https://martinfowler.com/arti…
左半局部的 单体架构 图：
单体利用将所有性能放到一个过程中
扩大：通过将整个利用复制到多态服务器实现扩大
右半局部的 微服务架构 图：
微服务架构将性能拆散，放到多个不同的过程中
扩大：通过将不同的服务散布于不同的服务器上，并按须要复制形式进行扩大
组织架构
- 单体利用的组织架构：
图片来自：https://martinfowler.com/arti…
它是一个整体式的利用团队，每个团队依照职能来进行划分（图片左半局部），比方：UI 团队，中间件团队，DBA 团队。
不同职能的人属于不同的团队。做我的项目的时候就从不同职能部门选出一些人来负责我的项目。这样的组织架构有一个问题就是：跨职能部门沟通协调问题。这种团队组织模式不能适应微服务架构的特点。
- 微服务利用组织架构
图片来自：https://martinfowler.com/arti…
微服务架构特点：每个微服务是独立的，团队能够独立开发，独立测试，独立部署，服务是自治的。相应的团队组成人员也有产品，技术，测试，团队成员在本人外部就能够残缺的进行微服务各种性能开发。
这就要突破原先传统的那种按职能划分的组织团队模式，而要把不同职能的人组织在一个团队内，组成一个跨职能的产品组织架构。这样能力把一个微服务性能架构、设计、开发、测试、部署、上线运行，在一个组织外部实现，从而造成残缺的业务、开发、交付闭环。
团队组织的变动
一图胜千言：
图片来自：https://insights.thoughtworks…
原先那种职能型的团队，变成了跨职能的小团队，这种团队和微服务架构对齐。
每个团队组织成员多少适合呢？
亚马逊的“两个披萨团队”，6-10 人的规模。这个只是一种参考，毕竟每个公司规模、业务、行业、成员等不一样，找到适宜本人的团队形成，就是最好的团队组织。
阐明：以上图片侵删，请分割主页邮箱！
四、怎么构建第一个微服务项目
- 第一种：有新我的项目，能够从 0 开始设计微服务架构。
-
第二种：革新旧有的老我的项目
这种也能够划分 2 类：- 从我的项目小范畴开始试水，进行革新。
- 齐全重构我的项目 – 个别不举荐这种形式。因为不仅老我的项目须要保护，而且来了新需要咋办？是老我的项目进行需要开发，还是新旧一起加，一起加又节约人力，不加技术跟不上业务倒退。这些危险都是须要思考掂量。
- 第三种：从边缘不重要的小我的项目开始。
这种我的项目需要开发个别不紧迫，我的项目又小，绝对独立，与现有零碎耦合较小，能够齐全重构。从这种小我的项目开始施行微服务，一步一步来构建，升高危险。
经验丰富后，在逐渐将其余我的项目进行革新。
这种是折中的方法，不是那种“休克疗法”。
五、参考
- https://martinfowler.com/articles/microservices.html Microservices
- https://martinfowler.com/bliki/MicroservicePremium.html
- https://insights.thoughtworks.cn/management-of-microservices-team/ 微服务化小团队集群的组织和治理