微服务架构学习系列文章：
- 微服务架构学习与思考(01)：什么是微服务？微服务的优势和劣势
- 微服务架构学习与思考(02)：微服务实施的前提条件？有哪些问题需要思考？
- 微服务架构学习与思考(03)：微服务总体架构图解
- 微服务架构学习与思考(04)：微服务技术体系
- 微服务架构学习与思考(05)：微服务架构适用场景分析
一、前言
“地址：https://www.cnblogs.com/jiujuan/p/13284412.html
前一篇文章简单分析了微服务的好处，以及会带来的问题。
遇到问题并不可怕，可怕的是我们不去面对它，不去想办法解决它，逃避问题是不可能有任何进步。所以积极想办法应对问题并解决问题，才能不断的进步。
前面讲了，微服务一般都是由单体演进而来，很少有业务从0就开始进行微服务开发。如果能从0就开始用微服务开发，确实是一件很好的事情，前提是你确实考虑清楚了用微服务开发适合当前的业务以及业务的发展需求。
那么问题来了，企业什么时候引入微服务呢？
二、企业什么时候引入微服务？
引入原因：
“单体应用无法满足业务增长的需求，业务的交付、业务的可靠性、稳定性要求，随着时间推移问题会越来越多。-- 也就是前面遇到的一些问题
“不过也有人，不是从本公司业务发展，开发成本，开发效率来考虑问题，而是什么开发大会上看到很多公司微服务的演讲，或者听说很多公司在用微服务，从这些方面来考虑，也就是随大流，这种思考方式显然不是正确思考方式。不要为了微服务而微服务。采用微服务收益一定要大于单体应用，要能解决遇到的问题。
从单体架构升级到微服务架构，肯定希望提高研发效率，缩短工期，加快产品交付速度。
那他们在具体生产效率上有什么区别？
根据马丁·福勒（Martin Fowler）的这篇文章，揭示了生产率和复杂度的关系。
在复杂度较小时，单体应用的生产率更高，微服务架构反而降低了生产率。但是，当复杂度到了一定规模，无论采用单体应用还是微服务架构，都会降低系统的生产率。区别是：单体应用生产率开始急剧下降，而微服务架构则能缓解生产率下降的程度。如下图：
x 轴是系统复杂度，y 轴是开发的生产力
绿色表示单体应用 蓝色表示微服务架构
单体应用和微服务有一个相交的点，这个点是单体应用生产率急剧下降，微服务平缓下降的交叉点，他们的生产效率开始出现不同。
这个点就是把单体应用切换到微服务的时间点。
但问题是，这个时间点，文章并没有具体说明什么时候会出现，怎么衡量这个时间点。 所以只能各个公司具体问题具体分析，技术领导者要考虑判断这个时间点。这也是考虑技术领导力的时候。不过有些要素可以参考：
业务角度 业务需求开发是否经常延迟 产品交付是否能跟上业务发展
研发质量 代码是否因为修改而经常出现bug 代码臃肿庞大
技术人员 有技术，有意愿 团队人数
等等一些考虑因素，在加上前一篇单体应用出现的一些问题。
- 更详细可以看看这篇文章：微服务架构适用场景分析
在考虑清楚之后，决定引入微服务，那么，又会遇到什么问题？
三、组织架构如何变化？
康威定律
“康威定律 (康威法则 , Conway's Law) 是马尔文·康威1967年提出的： 设计系统的架构受制于产生这些设计的组织的沟通结构。
康威定律告诉我们，如果我们实施了微服务，那么组织架构的变动也要跟着实施微服务架构而做出相应的调整。这样才有可能适应微服务的发展。
单体架构和微服务架构
先看看传统单体架构和微服务架构，如下图：
“图片来自：https://martinfowler.com/articles/microservices.html
左半部分的单体架构图： 单体应用将所有功能放到一个进程中 扩展：通过将整个应用复制到多态服务器实现扩展
右半部分的微服务架构图： 微服务架构将功能分离，放到多个不同的进程中 扩展：通过将不同的服务分布于不同的服务器上，并按需要复制方式进行扩展
组织架构
单体应用的组织架构： 
“图片来自：https://martinfowler.com/articles/microservices.html
它是一个整体式的应用团队，每个团队按照职能来进行划分（图片左半部分），比如：UI团队，中间件团队，DBA团队。
不同职能的人属于不同的团队。做项目的时候就从不同职能部门选出一些人来负责项目。这样的组织架构有一个问题就是：跨职能部门沟通协调问题。这种团队组织形式不能适应微服务架构的特点。
微服务应用组织架构 
“图片来自：https://martinfowler.com/articles/microservices.html
微服务架构特点：每个微服务是独立的，团队可以独立开发，独立测试，独立部署，服务是自治的。相应的团队组成人员也有产品，技术，测试，团队成员在自己内部就可以完整的进行微服务各种功能开发。
这就要打破原先传统的那种按职能划分的组织团队形式，而要把不同职能的人组织在一个团队内，组成一个跨职能的产品组织架构。这样才能把一个微服务功能架构、设计、开发、测试、部署、上线运行，在一个组织内部完成，从而形成完整的业务、开发、交付闭环。
团队组织的变化
一图胜千言：
“图片来自：https://insights.thoughtworks.cn/management-of-microservices-team/
原先那种职能型的团队，变成了跨职能的小团队，这种团队和微服务架构对齐。
每个团队组织成员多少合适呢？ 亚马逊的“两个披萨团队”，6-10人的规模。这个只是一种参考，毕竟每个公司规模、业务、行业、成员等不一样，找到适合自己的团队构成，就是最好的团队组织。
“说明： 以上图片侵删，请联系主页邮箱！
四、基础设施建设
这里的基础设施建设，指的是以 CI/CD 为基础的自动化交付流水线，到最后建设成从开发、测试、预发布、上线、运维等整个研发流程自动化的 DevOps 为目标。
因为随着微服务的逐步建设，服务数量增多，上线服务次数必然增多，交付频繁会带来故障次数增多，所以我们必须建设自动化的工具链，来帮助我们快速无误的交付服务，实施好微服务项目。
五、怎么构建第一个微服务项目
第一种：有新项目，可以从0开始设计微服务架构。
第二种：改造旧有的老项目 这种也可以划分2类：
从项目小范围开始试水，进行改造。 完全重构项目 - 一般不推荐这种方式。因为不仅老项目需要维护，而且来了新需求咋办？是老项目停止需求开发，还是新旧一起加，一起加又浪费人力，不加技术跟不上业务发展。这些风险都是需要思考衡量。
第三种：从边缘不重要的小项目开始。
这种项目需求开发一般不紧迫，项目又小，相对独立，与现有系统耦合较小，可以完全重构。从这种小项目开始实施微服务，一步一步来构建，降低风险。
经验丰富后，在逐步将其他项目进行改造。 这种是折中的办法，不是那种“休克疗法”。
六、参考
文章来源: 博客园
- 还没有人评论，欢迎说说您的想法！
客服
