《架构师》期刊摘要（2016年）一

一、《软件设计精要与模式》作者张逸在接收InfoQ采访时曾说：“评价一个架构的优劣方法之一是，把每个功能、非功能的因素扩大化，再看这个架构会不会出问题。”（本人赞同此说法）他的观点是说，架构设计要面向业务未来，而未来是不断发展的。架构不仅要承载业务的增长，还要兼顾技术发展的趋势。

《前言》（2016年6月）

 

二、我想任何人做架构多需要秉承“业务需求决定技术演化路线”的思路，那些暴露出来的现状和问题都驱动系统去转型，在系统和人之间找到一种最佳的合作模式，匹配已有的生产力和生成关系。正如软件开发学泰斗Kent Bech所说的：设计，是让你在长期过程中保持软件变化更加容易。

 

    在体量还不大的情况下，首先应该解决的是搭建好一套绝对稳定的基于模块化的平台，待体量逐渐长大、再去根据实际需求进行拆分、团队也随之变化。再下个阶段体量大道饱受单体模式智库，也应该首先建设平台服务，建设好之后，先按照大的粒度进行拆分，逐步再微服务化，否则，直接上服务化甚至微服务化都是非常危险的。

 

    微服务化就是以一系列小的服务开发支撑一个应用的方法论，服务独立在自己的进程中，通过轻量级通信机制交互（通常为HTTP），这些服务时围绕着业务上的组织结构来构建的，全自动的、独立部署。几乎看不到中心化的服务管理基础设施，可以使用不同的编程语言和数据存储技术来实现不同的服务。

《Building Microservices》一书中提到“微服务化就是一堆小而自治的服务，让他们一起工作起来”。微服务化的特点在于：

 

    1、模块即服务

    微服务中的组件在逻辑或者物理层次更趋于细分，这个细分不是极致的，而是一种力度适中的选择，通常这些组件在前期可以是一些模块，但是当需要时，例如业务上需要拆分独立，或者非功能需求上需要扩容等，都可以灵活的拆解出来。

    2、独立自治

    这意味着服务独立开发、独立测试，独立发布、独立部署、独立运维的，某个细分团队负责整个生命周期管理，这就是“康威定律”的通俗解释，官方解释是“一个组织的设计成果，其结构往往对应于这个组织中的沟通结构”，服务的规划不就是多人、跨团队协作的沟通模式吗？

    同时去除了牵一发而动全身的问题，单一职责的来进行修改需求或者重构一个点，开发和构建方便，不影响整个产品的功能，一个bug不会crash掉整个产品，针对不同的类型，区分“计算密集型”还是“IO密集型”，区分业务上更好使用关系型还是NoSQL，区分2/8原则（即80%经常修改的服务独立出来自成一家），区分短板功能、针对瓶颈可以做水平扩展、避免资源竞争，甚至可以区分技术栈、突破语言限制独立的服务可以实现非常大程度上的复用，服务之间依赖轻量级的接口，而不是模块。

 

    3、去中心化的数据管理

    微服务在服务拆分的同时，也需要将数据库分离，独立的服务维护独立的数据库，这对数据库也是减负，同时技术选型、SLA保证都会区分开来，把精力留给那些重要的业务数据库，进行分级的对待，而不能像以前那样一视同仁，一个不重要的逻辑库的bad SQL慢查询，阻塞了其他正常的查询，这事完全可以避免的。

    4、轻量级的通信协议

    传统的SOA使用ESB或者WebService这种重量级的解决方案，微服务推荐使用一些更轻量级的解决方案，要通用性，可以用RESTFul架构，使用HTTP通道，支持JSON序列化协议；需要高性能的，可以考虑使用高性能IO模型，比如Epoll、Actor等，基于TCP通道，使用protobuf序列化协议，同时保持长连接；要异步，可以通过持久的RabbitMQ或者高性能的ZeroMQ来做P2P、pub/sub等。而这种轻量级还需要体现在代码调用中，模块化直接通过函数、方法调用即可，服务化后能不能在API层面做到无侵入、无缝切换、简单配置，这些都是服务化框架要支持的。

    5、为失败设计

    服务化，因为着调用时跨进程的、分布式的，这种分布式特性引起的天然不可靠性，需要变为相对可控。也就是服务间的通信要架设不会成功，为失败处理。

    为了不影响整个产品，要做错误隔离，可以考虑熔断（circut break）、船舱隔离模式、限流、回退等手段，最后还有幂等性等问题（重试会不会对业务造成影响）。

    6、基础交付设施自动化

    这个特点是整个微服务中最大的亮点，包括持续集成CI、持续交付CD和Pass平台结合。微服务在细分的背景下，在project结果、物理结果上都提高了一个复杂度，就需要在基础交付上做一个大的转变，自动化部署则是必须的。

    

    微服务的缺点：

    1、分布式调用造成的性能、延迟问题。（可以采取的措施包括粒度适中、批量、高性能RPC、异步通信等）

    2、可靠性不好保证。（为失败而设计）

    3、数据一致性难以保证。（分布式设计本身涉及到的问题，最终一致性、强一致性等）

    4、整体复杂度提升。服务多、依赖多、调用多、契约如何管理、监控如何做，调用链上怎么确定哪个点有问题，服务的SLA保障、性能、错误率、告警、集成测试、部署等。

 

    架构只是标准、骨骼，对微服务的讨论不应该让我们忘记了更重要的问题，驱动软件项目成功和失败的重要因素。软因素，比如团队中人的素质、以及他们如何彼此合作、沟通，这都会丢是否使用微服务有很大的影响。在纯技术层面上来讲，应该把重点放在干净的代码、完善到位的测试，并持续关注架构演进，这才是一个软件工程师的根本职责。

《谈谈后端业务系统的微服务化改造》（2016年6月）

 

三、传统的企业级应用是单体应用，一般是分层结构，如表现层、应用层、领域层、数据层，这主要是水平切分的思想。

    随着互联网应用的发展，特别是大型电商系统，业务非常复杂。这种巨型系统，首先要关注的是如何根据业务划分子系统，然后是子系统间如何协作，最后才是子系统内部实现。SOA设计可以有效支持前面两步，在SOA体系里，每个子系统是独立的服务，服务接口体现子系统协作关系，至于子系统内部，直接作为黑盒处理。

 

    所以对于复杂系统，首先采用SOA垂直切分子系统，然后使用分层设计水平切分大单个子系统，服务化把传统的分层设计往前更推进一步。

 

    当然SOA本身也在不断发展，最初跨企业的Web Service交互可以认为1.0时代，支持企业内部系统间轻量级访问、支持服务治理，可认为是2.0时代；服务进一步分层和微服务化可认为3.0时代。

 

    “业务在变，技术在变，架构也在变。变的是形式，不变的是本质，架构为了系统更有序，系统为了业务更快速，业务为了生活更美好”。

《卷首语--架构发展趋势和现状》（2016年三月）

四、

    “KumuluzEE是第一个使用标准Java API的微服务框架。微服务架构的重点是将应用程序开发成服务并将这些服务单独部署；没有一个框架提供自动化部署和配置，是不可能使用JavaEE实现真正的微服务架构的”。