■王刚
从几年前某CTO的一个问题说起：“我们的系统将会拥有5000个微服务组件，我们应该怎么做？”
一个接口是无法称之为微服务的，接口数量达到十几个或许才够称之为微服务。那么，对于包含5000个微服务的系统而言，该如何实现和管理呢？在这样庞大的系统背后，一定存在很大的问题。
微服务的前世今生
微服务是如何诞生的，必须了解以下4个领域。
TOGAF：全称“开放组体系结构框架”，TOGAF在上世纪七、八十年代的时候就已经由专门组织负责开发了，直到1995年美国国防部参与之后，TOGAF才最终成型。
如今，大家手机里正在使用的产品和应用中，很多都会用到SAP、IBM或者惠普的软件，而这些软件公司所遵循的就是TOGAF。可以说目前全球超过50%的企业正在使用TOGAF实践软件架构设计和开发。
TOGAF是一个架构体系，但并没有提供具体的架构方法。TOGAF包含了业务架构、应用架构、数据架构、技术架构等，TOGAF有3个最为主要的支柱：
企业架构域，主要是企业信息与业务流等；
ADM一系列的架构方法论；
企业连续性，指的是在企业业务高速增长并且不断变更的过程中，保证架构体系的连续性。微服务在哪里
DDD：全称为“领域驱动设计”，其包含了诸多的概念，可以用3句话进行概括：
DDD是精简的业务，DDD首先关注的就是业务，把各种繁琐的业务流程精简成更细的链条；
DDD需要回答业务是干什么的，能够满足什么需求，达成什么目的；
不断迭代，DDD的不断迭代与TOGAF的企业连续性类似。
SOA：全称为“面向服务架构”，理论较多，但是可以总结为以下3点：
SOA解决了信息孤岛的问题；
业务重用，从业务角度将各个服务组合成一个个中间件或者服务，将其提供给用户或者其他系统；
SOA使得系统成为互联互通的信息。
GRASP原则：全称为“通用职责分配原则”，包含很多耳熟能详的概念如低耦合、高内聚，均来自GRASP原则。它与设计模式不同，设计模式指导如何实现系统，而GRASP旨在指导如何划分。
GRASP原则旨在指导定义业务架构以及API等相关内容和划分服务，其理论内容也非常多，但只需记住3个关键：自己干自己的事；
自己只干自己能干的事；
自己只干自己的事，强调了资源划分。
在软件工程的教科书上给出了微服务架构的定义：微服务架构是一种架构模式，它是将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常基于HTTP协议的RESTFul API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下游，选择合适的语言、工具对其进行构建。
微服务带来的优势
我们使用微服务架构的时候，到底得到了什么东西呢？这里总结了4点最为明显的优点：
使得开发和迭代变得更加敏捷，微服务架构使得敏捷开发成为可能；
易于扩展和收缩，一些公司基于Kubernetes、Docker等技术可以在几秒内拉起上万个微服务，当大型流量冲击到达的时候，可以实现无损地承担全部流量，同时实现用户无感知，而当数据访问量降低之后，又可以实现快速缩容；
多技术栈可能，目前云智慧的技术栈非常全面，虽然开发人员只有60多人，但是开发语言却多达10多门，而使用微服务可以有效地组织各类开发人员；
高可修改性，比如实现数据库的快速迁移，通道的快速切换等。
微服务带来的疑问
微服务能够带来诸多优点，但是也存在2点疑问，第一个就是“微服务架构，你的系统变得更健壮了吗？”；第二个则是“使用微服务让系统变得更快了吗？”
对于这2点而言，可能说是见仁见智的。有人说因为组件变得越来越多，可监控性就会变难，因此系统健壮性就会变得越来越差；也有人说因为将系统拆分得越来越细，因此健壮性就会越来越强。如果单体架构是串行的，那么使用微服务可以将其变成并行的和分布式的，而多个组件之间进行通信，也会使得通信成为性能瓶颈，那么使用微服务到底是
变快了还是变慢了呢？这2个问题都很难以回答，作为一个架构师或者开发者需要不断进行深入的思考。
微服务架构面临的挑战和思考
这里总结了在使用微服务架构的时候所需要面临的8个挑战和相关的思考：
小即是多
当业务从大变小的时候，也意味着业务变多了。由大变小，可以使系统变得更加容易维护和修改，但是由少变多，又会使得问题更加复杂，因此也会出现很多的挑战。
第一个问题就是多节点、多服务和多状态。系统中的节点、组件服务变得更多了，那么节点和服务之间的状态也会变得更难维护，更加复杂。基于前面提到的4种知识，可以将从大变小和从少变多这2个转变进行折中，使得其变得更加可控。而解决这个问题的关键在于对于服务的合理拆分，主要有3点可以考虑，即：数据资源、业务功能以及服务对象。
债务管理
Bug、代码缺陷、未完成的功能或者版本不兼容等问题都是债务，当服务变得越来越多的时候，债务往往就会变得更多。为了解决这些问题，有这样的几种策略：
单元测试，如果单元测试做的足够好，那么代码缺陷的可能性就会变得更低，可以将服务由少变多所造成的债务变多问题进行收敛。
集成回归，这部分提供了很多工具去做这件事情，不用开发者自己去做。
版本管理，这里指的是静态库的版本管理，动态库指的是正在变更中的库，而静态库指的是不再变更的库和配置项，这一点控制不好，就容易使得系统管理混乱。
迭代冲刺，是一种组织方式，当有很多技术债务需要进行管理时，如何将这些债务一点点处理掉或者把发散的趋势收敛住，迭代冲刺就是一种做法。
Bug Crash，这是智慧云团队自己发明的一个名词，相当于是对于Bug的大扫除，无论采用传统的还是敏捷的开发模式，都有一些Bug存在，因此定期会组织全体开发、测试和产品人员将自己的产品用一遍，进行Bug大扫除。
总之，无论采用什么开发模式，在一个迭代周期完成之后，回归总结是少不了的，也需要通过一些方法解决新发生的问题，或者将其封闭住不使债务继续蔓延。
复杂的服务依赖
如果只有一个或者几个组件，那么其实不存在服务依赖问题，而如果有几千个组件，那么服务依赖将会成为巨大的问题。举例而言，如果用户服务需要调用订单服务，那么在启动的时候需要进行一些初始化任务，那么一个服务的版本发布可能导致系统全面瘫痪，这就是复杂服务依赖问题。
为了解决这个问题首先就需要服务发现机制，比如使用etcd或者Zookeeper等，首先服务发现中心也需要是分布式高可靠的，那么服务起来之后需要把自己的名字和调用方式告诉服务发现中心，注册上去；对于服务调用者而言只需要从服务发现中心那里通过约定好的名字获取服务调用地址即可。
依赖唤醒是有一个相对比较新的东西，比如大流量突然打进来的时候，A服务需要从原来的10个启动到100个，而B肯定也是不够用的，因此需要通过唤醒的机制将服务拉起来，而不是被动的等通知。
还有一种情况也需要使用到依赖唤醒机制，比如缓存穿透问题，正常情况下，缓存是生效的，不会存在穿透的情况，但是可能因为某种异常使得缓存不生效了，会将大量的流量打到DB里面去，使得服务变得不可用了，整个服务雪崩掉，针对这些问题一般会开发一些挡板服务，可能会给出一些固定的数据，而这些挡板服务也有可能会面临这种突发的流量也需要通过依赖唤醒的机制实现唤醒。
此外，还有灰度发布和AB测试，这2点是相关联的。还有多版本共存问题，对于服务的多版本也是一个技术债务问题，需要考虑如何将其旧版本拿下来。
消息通信
如果系统中包含多个语言栈，多种实现方式。那统一标准是必须的，统一一种RPC或者就使用RestFul API等。消息中心也是一种处理做法，这一点在Java中应用很多，消息中心并不是消息队列，而是一个事件驱动的消息中心。此外，还有通信网关，这在使用微服务的时候也是一个必要点，其主要解决了监控问题，而且可以通过网关起到中控的作用，比如安全、性能以及用户校验等任务。
分布式事务
在实现分布式事务的时候可以采用2PC或者3PC原则来实现，2PC原则是通过全部节点投票和执行2个步骤完成的，并且是阻塞的；而3PC则不同，在一个具体的事务里面可以是阻塞的，也可以是非阻塞的。
3PC协议则是通过“Can-Pre-Do”3个步骤来实现的，其实PDU就是3PC协议在单体中的实现方式。而在分布式系统中，3PC有3种实现方式，使用分布式的事件驱动、最大通知以及两阶段补偿TCC。
花式故障
很多时候，当系统出现问题时可能需要花费数周和很多人力才能到根源所在，可能因为系统太多，使得系统架构师也无法理清系统与系统之间的关系。面对诸多的花式故障，也有多种策略可以应对，
比如全链路追踪，比如使用Open Tracking；主动拨测，很多用户端的App里面内置探针，使其可以接收Server端的指令来定期探测接口和服务是否正常。
中心与去中心
中心与去中心可以算是一个永恒的话题，配置、发号、日志、调度、状态以及预警，其实对于比较成熟的大型系统而言，这6点都是需要中心的。
组织危机
最后一个问题，也是最大的问题。要实现向微服务架构的变更的时候，最大的问题就是组织危机。这一点与开发者关系不大，但是对于Team Leader以及组织的管理人员而言，关系非常大。架构的转变需要考虑到信任危机、过期维护、多语言栈、沟通协作、安全网关以及轮岗结对等问题。
总之，最重要的观点有2个：微服务不是银弹；不要让重复的事情做2次。
■孙启航
新冠疫情带来了大量的隐患，冲击着领导公司的传统方法，使企业决定适应新常态。在家工作是疫情带来的最明显影响。它改变了企业活动，要求采用远程办公的方式。IT团队一直扮演不可或缺的角，他们的工作在支持这种新模式方面比以往任何时候更明确无误。CIO有责任保证公司代表和同事在外面工作时，配备合适的设备，并随时待命。
后疫情时代，面对不可测的世界，加速数字化转型的企业往往更能未雨绸缪。展望未来，IT团队必须从过去汲取经验，准备好可靠、适应性强和灵活的安排及方法。
那么，CIO如何才能拥抱疫情带来的变化，并使企业适应未来的需要呢？
整改传统技术
在居家办公和适应快速的业务变化期间，老式框架的缺陷暴露无遗。获取组织的数据，并与来自众多地方、使用诸多设备的客户进行沟通，当前的IT资产架构满足不了需求；由于不稳定的工作场所，危险和弱点随之而来，引发了令人不安的担忧。
对一些组织而言，网络攻击数量激增，网络安全受到了前所未有的威胁。据IBM的报告显示，纵观全球，2020年信息泄露的平均成本为386万美元。这么一来，要想在后疫情时代的协同工作和沟通支持方面占据上风，必须升级网络和安全框架。
因此，修补或更新服务器是一种出的方法：出差距、整改现有的系统，积极采用新方法（比如SSL VPN、ADC 和防火墙），以及保护Web和便携式应用程序。这可以保护企业远离远程工作带来的更多风险，让企业为适应新的办公模式做好准备。
推行数字优先方法
疫情提升了人们对技术的普遍期望：从采用云技术到远程工作，再到为混合办公做准备，CIO已经在最艰难的时期接受了办公方式的变革，并向公司代表、员工和客户传达了信息。虽然疫情需要快速而安全地提供服务，但CIO目前需要推动数字优先的方法，以紧跟指导准则。对于CIO来说，这是大好机会，可以作为先驱者脱颖而出，朝富有成效的变革前进；其中，企业应该拥有由最新创新驱动的适当行动计划。合适的创新组合应促进适应能力、开发和服务的快速交付，同时保持低成本和简约性。
保持敏捷性和弹性
“变化是唯一不变的”——
—这句话在当下再重要不过了。尽管疫情使CIO肩负重任，但也因此提供了良机。这些不可预测和复杂的情形要求组织采用经过协调的方式，以改善客户体验、员工成效、任务和安全等。
CIO可以通过帮助变革和支持执行类似的工作来熟悉新的创新，从而培养敏捷文化。比如说，假设公
司代表将不起眼又单调的工作交给人工智能/机器学习和机器人程序方面的创新；再比如，让公司代表了解基本的安全边界，以牢牢控制报复性邮件及其他网络犯罪陷阱。创新可以通过增强沟通和合作来实现，提高公司代表的技术认知，并填补远程工作造成的漏洞。
为混合劳动力做好准备
虽然最初强行要求在家工作，但管理人员现在不得不承认异地工作可能很有用。此外，这种工作模式还有几个额外的好处，比如减少开支和充分利用全球劳动力。因此，CIO需要接受另一个挑战：混合劳动力。想象一下未来，一些员工在家工作，一些在办公室工作，还有一些兼而有之。因此，在公司内外使用个人和办公设备可能会使企业面临更高的威胁风险。另外，如果这种情形成真，黑客也许会乘虚而入，因此必须为混合劳动力做好准备。
IT团队在赋予工作角、制定创新行动计划以及跟上业务多样性方面发挥着关键作用。尽管CIO及其团队一直在努力帮助企业采用全新的工作方式，但当前这个时代无疑是支持企业未来发展的理想机会。缓解网络风险和抵御攻击，部署当今的创新技术，并采用数字优先的方法，这对于未来的CIO至关重要。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。