目录
一、微服务架构实施的前提
如图，Martin Fowler结石的生产率和复复杂度的关系。可以看出：
1.当复杂度较小时，采用单块系统的生产率更高，微服务架构反而可能降低生产率。
2.当复杂度达到一定规模时，无论单块系统还是微服务架构都会降低生产率，但是单块系统会面临急剧下降的情况，而微服务架构相对平稳。
3.我们发现有一个明显的拐点存在，但是并没有量化这个拐点的具体大小，也就是说系统或代码的规模达到具体多大适合进行微服务的拆分，这个需要各个团队因地制宜。
4.只有当出现这个拐点时对系统进行微服务化的拆分才是合适的方案，服务的合理拆分是实施微服务架构的一大前提。
5.微服务的实施需要基础设施自动化，这和服务规模有关，从开发之后的构建、测试、部署都需要高度自动化的环境来支撑才能有效降低边际成本。
二、微服务实施的三大模式
1.典型模式：从一个单块系统开始逐步转变到多个维度的微服务架构。
2.从无到有的实施，但是小系统没有必要直接采用微服务架构。
3.混合式，微服务架构很容易与现有系统并存，微服务与遗留系统的易整合性也是采用微服务的一个主要原因。
三、实施微服务架构的优势
基本优势可如图分析：
实际例子举例，如图：
（一）、六大技术优势
1.组件化方案：高内聚，低耦合；
2.技术自由度：每个微服务高度独立，可以采用适合自身开发团队和技术体系的工具和框架来实现某个微服务；
3.可扩展性：单个微服务在保证通信方式不变的情况下，对其内部功能和技术的改变不会对外部依赖它的服务产生任何影响；
4.可伸缩性：注意可以伸缩的前提是对系统有合理的划分，高扩展往往能够带来高可伸缩性；
5.有效应对遗留系统：微服务时改造遗留系统的强有力武器，只要可以获得遗留系统的暴露接口，微服务架构就能与之进行通信并完成功能整合。
6.持续可交付：简单、可重复流程确保软件发布过程的可靠性。
（二）、业务与组织优势
康威定律，组织形式等同于系统设计，直白的说就是，你想要什么样的系统就搭建什么样的团队。
举例：原有的功能团队—————–微服务架构的自治性组织文化（大系统变为小系统、小产品）
1.消除过程浪费
可采用产品开发周期与成本之间的关系开分析：明确的边界有助于减少团队之间的扯皮现象，提升开发效率。
2.快速产品开发
通过技术创新缩短同行产品开发周期，具体分析如图：
四、实施微服务面临的挑战
（一）、技术架构的挑战
1.去中心化与平衡：去中心化的思想意味着微服务之间不需要共享技术，然而缺少通用技术体系同样会加剧系统的复杂度，当从统一发布和运维等角度去看待整体系统时，这种技术复杂度可能会是一个问题，需要进行平衡。
2.服务版本控制：提倡为每个微服务建立版本并根据业务迭代更新版本，那么需要考虑在多版本更新频率很高时，应充分思考如何正确管理服务版本。
（二）、研发过程的挑战
1.需求的边界：如何确定业务功能的粒度、如何把非功能性需求分解到各个微服务中、如何从系统整体上把握需求的优先级等；
2.引入变化：当微服务架构被引入时，依旧需要做很多事情，因为我们所提到的各种技术、架构和过程的挑战需要我们跟踪和协调。
参考书籍、文献和资料：
【1】郑天民. 微服务设计原理与架构. 北京：人民邮电出版社，2018.
【2】Sam Newman. 微服务设计[M]. 崔力强，张骏译. 北京：人民邮电出版社，2016.
【3】 MartinLAbbott, MichaelT.Fisher. 架构即未来：现代企业可扩展的Web架构、流程和组织[M]. 陈斌译. 北京：机械工业出版社，2016.
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/204086.html原文链接：https://javaforall.net
