（给ImportNew加星标，提高Java专业技能）
Bokaro：cyfonly
看到前段时间“微服务项目构架”那个基本概念那么火，作为一个积极主动勤奋的流程猿，成小黑禁不住想自学自学。而构架师老张（不是顶楼老张）前段时间正好在做公司此基础服务项目的微服务项目化科学研究和破冰，为此德圣茹。
只好成小黑立刻屁颠屁颠的跑过去向老张求教：“柳哥，我看微服务项目构架那么火，我也先挑，您给我谈谈啥是微服务项目构架呗？”
老张笑了笑说：“要想晓得甚么是微服务项目构架，你得先晓得甚么控制系统构架设计。”
成小黑的平庸是成为一位构架师，平常累积了许多科学知识，因而对“控制系统构架设计”那个基本概念还是很熟识的，因而他立刻就得出了标准答案【1】：
控制系统构架设计叙述了在应用领域控制系统的外部，如何根据业务、控制技术、组织、稳定性、扩展性以及可移植性等多种不同不利因素，将应用领域控制系统分割成相同的部份，并使这些部份彼此间互相社会分工、互相合作，进而为使用者提供这种某一的价值的方式。
老张令人满意的笑了笑，继续问：“你看前段时间我在做微服务项目的科学研究和破冰，你晓得为甚么要做那个事吗？”
“因为现阶段的四层构架存在很多弊病，不满足用户销售业务产业发展的市场需求了呗。”
“对的，我看你对子公司现阶段的构架也十分熟识了，你来细细说说现在的四层构架吧。”
只好成小黑拿了两张A4纸，通俗易懂地给老张讲了他对四层构架的认知：
四层构架是指在销售业务和控制技术的产业发展过程中，控制系统中相同职能的部份被表述在相同的层级，每几层负责管理的机能更为抽象化。四层构架一般来说包括links、销售业务方法论层和数据访问层，层与层之间互相连接、互相协作，构成一个整体，并且层的外部可以被替换成其他可以工作的部份，但对整体的影响不大。
以 Web 应用领域流程为例，早期是将所有的表示方法论、销售业务方法论和数据访问方法论放在一起，这就是几层构架。
后来随着 java、.NET 等高级语言的产业发展，提供了越来越方便的数据访问机制，如 java 的 JDBC 和 .NET 的 ADO.NET。这时数据访问部份被分离开来，形成了二层构架。
再后来，随着面向对象设计、企业构架模式等理念的不断产业发展，表示方法论和销售业务方法论也被分离开来，形成了现在的四层构架。
四层构架的具体内容如下：
links： 使用者使用应用领域流程时，看到的、听见的、输入的或者交互的部分。
销售业务方法论层： 根据使用者输入的信息，进行方法论计算或者销售业务处理的部份。
老张对那个解释非常令人满意，作了进一步的补充：“你看虽然现在流程被分成了四层，但只是方法论上的分层，并不是物理上的分层。也就是说，对相同层的代码而言，经过编译、打包和部署后，所有的代码最终还是运行在同一个进程中。而这，就是所谓的单块构架。”
成小黑挠了挠头：“原来单块构架是那个意思啊~~”
“嗯。根据你的实际工作经验，你再总结下单块构架的优缺点吧。”
平常勤于总结的成小黑很快便列出了单块构架的优缺点：
优点：
易于开发： 开发方式简单，IDE 支持好，方便运行和调试。
易于测试： 所有机能运行在一个进程中，一旦进程启动，便可以进行控制系统测试。
易于部署： 只需要将打好的一个软件包发布到服务项目器即可。
易于水平伸缩： 只需要创建一个服务项目器节点，配置好运行时环境，再将软件包发布到新服务项目器节点即可运行流程（当然也需要采取分发策略保证请求能有效地分发到新节点）。
缺点：
维护成本大： 当应用领域流程的机能越来越多、团队越来越大时，沟通成本、管理成本显著增加。当出现 bug 时，可能引起 bug 的原因组合越来越多，导致分析、定位和修复的成本增加；并且在对全局机能缺乏深度认知的情况下，容易在修复 bug 时引入新的 bug。
持续交付周期长： 构建和部署时间会随着机能的增多而增加，任何细微的修改都会触发部署流水线。
新人培养周期长： 新成员了解背景、熟识销售业务和配置环境的时间越来越长。
控制技术选型成本高： 单块构架倾向于采用统一的控制技术平台或方案来解决所有问题，如果后续想引入新的控制技术或框架，成本和风险都很大。
扩展性差： 随着机能的增加，垂直扩展的成本将会越来越大；而对于水平扩展而言，因为所有代码都运行在同一个进程，没办法做到针对应用领域流程的部份机能做独立的扩展。
老张拍了拍成小黑的肩膀，眼睛眯成了一条缝：“小伙子总结的很不错！既然你已经对现阶段的单块构架的优缺点有了很好的认知，那现在咱们就可以开始来自学微服务项目构架了。”
老张先从网上搜索“微服务项目构架”关键字，出来那么一段话：
微服务项目构架是一种构架模式，它提倡将单一应用领域流程分割成一组小的服务项目，服务项目之间互相协调、互相配合，为使用者提供最终价值。每个服务项目运行在其独立的进程中，服务项目于服务项目间采用轻量级的通信机制互相沟通（一般来说是基于 HTTP 的 RESTful API）。每个服务项目都围绕着具体销售业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务项目管理机制，对具体的一个服务项目而言，应根据销售业务上下文，选择合适的语言、工具对其进行构建。
成小黑看完了这段话，说：“看着有点晕，云里雾里的感觉……”
老张嘿嘿一笑：“莫慌，现在就给你详细谈谈微服务项目构架的特性。”
1. 单一职能
微服务项目构架中的每个服务项目，都是具有销售业务方法论的，符合高内聚、低耦合原则以及单一职能原则的单元，相同的服务项目通过“管道”的方式灵活组合，进而构建出庞大的控制系统。
2. 轻量级通信
服务项目之间通过轻量级的通信机制实现互通互联，而所谓的轻量级，一般来说指语言无关、平台无关的交互方式。
对于轻量级通信的格式而言，我们熟识的 XML 和 JSON，它们是语言无关、平台无关的；对于通信的协议而言，一般来说基于 HTTP，能让服务项目间的通信变得标准化、无状态化。现阶段大家熟识的 REST（Representational State Transfer）是实现服务项目间互相协作的轻量级通信机制之一。使用轻量级通信机制，可以让团队选择更适合的语言、工具或者平台来开发服务项目本身。
3. 独立性
每个服务项目在应用领域交付过程中，独立地开发、测试和部署。
在单块构架中所有机能都在同一个代码库，机能的开发不具有独立性；当相同小组完成多个机能后，需要经过集成和回归测试，测试过程也不具有独立性；当测试完成后，应用领域被构建成一个包，如果某个机能存在 bug，将导致整个部署失败或者回滚。
在微服务项目构架中，每个服务项目都是独立的销售业务单元，与其他服务项目高度解耦，只需要改变当前服务项目本身，就可以完成独立的开发、测试和部署。
4. 进程隔离
单块构架中，整个控制系统运行在同一个进程中，当应用领域进行部署时，必须停掉当前正在运行的应用领域，部署完成后再重启进程，无法做到独立部署。
有时候我们会将重复的代码抽取出来封装成组件，在单块构架中，组件一般来说的形态叫做共享库（如 jar 包或者 DLL），但是当流程运行时，所有组件最终也会被加载到同一进程中运行。
在微服务项目构架中，应用领域流程由多个服务项目组成，每个服务项目都是高度自治的独立销售业务实体，可以运行在独立的进程中，相同的服务项目能十分容易地部署到相同的主机上。
理论上所有服务项目可以部署在同一个服务项目器节点，但是并不推荐那么做，因为微服务项目构架的主旨就是高度自治和高度隔离。
“王哥你真厉害，您那么一说我的思维清晰了很多！”成小黑激动的几乎要叫起来。
“我之前了解过 SOA，好像跟微服务项目构架的思想很像啊，您能帮我区分一下吗？”成小黑追问到。
老张嘿嘿一笑，拿起成小黑手上的A4纸，翻到另外一面画了个表格：
成小黑看了之后说：“您那么一画我倒是大概明白了，但是 DevOps 那个基本概念我不懂诶……”
“那个 DevOps 就说来话长了，有时间你自己先去查查资料了解下吧。”
“好的。现在我对微服务项目构架的基本概念有了了解，您能再深入剖析下它的本质吗？”
“好，你可细细听好了哈！”
1. 服务项目作为组件
微服务项目也可以被认为是一种组件，但是跟传统组件的区别在于它可以独立部署，因而它的一个显著的优势。另外一个优点是，它在组件与组件之间表述了清晰的、语言无关、平台无关的规范接口，耦合度低，稳定性十分高。但它的不足之处是，分布式调用严重依赖于网络的可靠性和稳定性。
2. 围绕销售业务组织团队
在单块构架中，企业一般会根据专业技能分割团队，在这种组织构架下，即便是简单的市场需求变更都有可能需要跨团队协作，沟通成本很高。而在微服务项目构架中，它提倡以销售业务为核心，按照销售业务能力来组织团队，团队中的成员具有多样性的专业技能。
品而非项目
在单块构架中，应用领域基本上是基于“项目模式”构建的，即项目启动时从相同专业技能资源池中抽取相关资源组成团队，项目结束后释放所有资源。这种情况下团队成员缺乏主人翁意识和产品成就感。
在微服务项目构架中，提倡采用“产品模式”构建，即更倾向于让团队负责管理整个服务项目的生命周期，以便提供更优质的服务项目。
4. 控制技术多样性
微服务项目构架中，提倡针对相同的销售业务特征选择合适的控制技术方案，有针对性的解决具体销售业务问题，而不是像单块架构中采用统一的平台或控制技术来解决所有问题。
5. 销售业务数据独立
随着销售业务的产业发展，可以方便地选择更合的工具管理或者迁移销售业务数据。
6. 此基础设施自动化
微服务项目构架提供自主管理其相关的销售业务数据，这样可以随着销售业务的发展提供数据接口集成，而不是以数据库的方式同其他服务项目集成。另外，在微服务项目构架的实践过程中，对持续交付和部署流水线的要求很高，将促进企业不断寻找更高效的方式完成此基础设施的自动化及 DevOps 运维能力的提升。
听完成小黑禁不住表达了敬佩之意：“老司机就是老司机，噢说错了……构架师就是构架师，总结得那么简洁又深刻！”
“咳咳，低调低调……”
“听您讲解了那么多，我觉得微服务项目构架解决了很多当前四层构架的痛点。不过我觉得没有任何一项控制技术或构架是完美的。”
“十分正确。进行微服务项目构架的破冰是存在很多挑战的。”
1. 分布式控制系统的复杂性
微服务项目构架是基于分布式的控制系统，而构建分布式控制系统必然会带来额外的开销。
性能： 分布式控制系统是跨进程、跨网络的调用，受网络延迟和带宽的影响。
可靠性： 由于高度依赖于网络状况，任何一次的远程调用都有可能失败，随着服务项目的增多还会出现更多的潜在故障点。因而，如何提高控制系统的可靠性、降低因网络引起的故障率，是控制系统构建的一大挑战。
异步： 异步通信大大增加了机能实现的复杂度，并且伴随着定位难、调试难等问题。
数据一致性： 要保证分布式控制系统的数据强一致性，成本是十分高的，需要在 C（一致性）A（可用性）P（分区容错性） 三者之间做出权衡。
2. 运维成本
运维主要包括配置、部署、监控与告警和日志收集四大方面。微服务项目构架中，每个服务项目都需要独立地配置、部署、监控和收集日志，成本呈指数级增长。
3. 自动化部署
在微服务项目构架中，每个服务项目都独立部署，交付周期短且频率高，人工部署已经无法适应销售业务的快速变化。因而如何有效地构建自动化部署体系，是微服务项目面临的另一个挑战。
4. DevOps 与组织构架
在微服务项目构架的实施过程中，开发人员和运维人员的角色发生了变化，开发者将承担起整个服务项目的生命周期的责任，包括部署和监控；而运维则更倾向于顾问式的角色，尽早考虑服务项目如何部署。因而，按需调整组织构架、构建全机能的团队，也是一个不小的挑战。
5. 服务项目间的依赖测试
单块构架中，一般来说使用集成测试来验证依赖是否正常。而在微服务项目构架中，服务项目数量众多，每个服务项目都是独立的销售业务单元，服务项目主要通过接口进行交互，如何保证依赖的正常，是测试面临的主要挑战。
6. 服务项目间的依赖管理
微服务项目构架中，服务项目数量众多，如何清晰有效地展示服务项目间的依赖关系也是个不小的挑战。
“微服务项目的破冰需要经过全面的考察和完善的试验，并不是每个场景都适合使用微服务项目构架，也不是每个企业都有能力或者精力去面对这些挑战。”老张最后语重心长的说。
“嗯嗯，每件事都有两面性，最合适的才是最好的！对了柳哥，您已经给我上完理论课了，啥时候带我实践下呗？”
“你先好好消化完今天讲的这些，下次再说吧……”
“好吧，很期待我们的下一次交流……”
推荐阅读
（点击标题可跳转阅读）
多科学研究些构架，少谈些框架（ 1 ）: 论微服务项目构架的核心基本概念
多科学研究些构架，少谈些框架（ 2 ）：微服务项目和充血模型
微服务构架下静态数据通用缓存机制
看完本文有收获？请转发分享给更多人
喜欢就点一下「好看」呗~
