These two days of the evolution of the Internet architecture was simple to understand, and very interested in the emergence of micro-services, so the knowledge of a simple collation and summary.
This article briefly describes the evolution of the Internet architecture, and then introduced as a service, and finally introduces micro-services and the latest Service Grid (Service Mesh).
---------------------
The evolution of the Internet architecture
Integrated architecture
In the early development of computer software, desktop software in general are using this architecture, the interface or whether it is business process or data processing are placed in a package. This fact alone architecture, but also it can be said that good architecture, because it is simple enough.
mvc architecture
But with the advent of the browser will produce a web application, web application features are part of the interface is displayed in the browser, the service processing in the service of the vessel, the page shows the general use css + js + html technology to deal with, then end can java, php like language, which produces a separated front and rear ends. For web system, one architecture can not meet the development needs of the front and rear end of the separation, which will produce the MVC architecture.
MVC considered on architecture in the true sense, because in addition to solve the problem of separating the front and rear end, also introduces a new development model, in a business logic, data, interface display method for separating the organization code, making the entire application better definition, but only reduce the coupling between all levels, but also improve all levels of reusability.
But with the growing size of the application, the application module is increasing, the whole application has become increasingly bloated, it is also more difficult to maintain, so in turn produced a multi-application architecture.
Multi-application architecture
Multi-application architecture is very simple, that is the original application into multiple applications according to business characteristics. For example, a major electricity supplier system may contain user system, merchandise system, order system, evaluation system and so on, we can separate them out a separate application form. Features multi-application architecture is independent between applications, they do not call each other.
Multi-application solves the problem of bloated applications, but are independent applications, some common business or code can not be reused.
Distributed Architecture
For a large Internet systems, typically contain multiple applications, and often there is a common business between applications, and also there is a call relationship between applications. In addition, there are other challenges for large-scale Internet system, such as how to deal with the rapid growth of the user, how to manage the R & D team fast iterative product development, how to maintain a more stable product upgrades and so on.
Therefore, in order to get a good business reuse, modularity, easier to maintain and expand, we want to separate business and application, a business no longer belongs to an application, but as a stand-alone service for maintenance alone. Bloated application itself is no longer a module stacking, but a combination of a modular service components together.
Service of
Service-oriented features
Distributed architecture described above that is service oriented. Let us sum up, as a service mainly has the following characteristics:
- Application by business split into service
- Each service can be deployed independently
- Service can be shared by multiple applications
- Can communicate between service
Service-oriented benefits
So what are the benefits and services of the companies have adopted it?
- Architecture on the system clearer
- Stable core modules to upgrade the service components as a unit, eliminating the risk caused by the frequent release
- Development and management easy
- Separate maintenance team, working clear, clear responsibilities
- Service multiplexing, code reuse
- Very easy to expand
Service of implementation
If you want to implement a service-oriented words, the most common way is to use RPC framework. Because the service components usually run on different servers, so to achieve the first problem to be solved is the service of remote service invocation RPC ** **. RPC has many similar programs, such as:
- Java RMI
- WebService
- Hessian
- Http
- Thrift
- … …
Confronted with the challenge of service
To achieve the above-mentioned services of first need to solve the problem of remote service calls, in addition, there are many other problems to solve.
- Service more and more complex configuration management
- Room service dependencies complex
- Load balancing between service
- Expand services
- Service Monitoring
- Service downgraded
- Authentication Service
- Services on the line and off the assembly line
- The service document
- … …
Service Management
The above mentioned service oriented, in fact, in order to service, service governance is the key. Then there is no good governance programs and services it? The answer is yes, and many people are using this framework, he is -dubbo. dubbo is a service management framework with RPC functions.
dubbo provides a more complete service management program, so if you want to implement a service oriented business, then, dubbo is a good choice. Here briefly dubbo service governance-related programs.
Service Discovery Register
服务治理领域最重要的问题就是服务发现与注册。dubbo中引入了一个注册中心的概念，服务的注册与发现主要就依赖这个服务中心。
dubbo注册中心服务注册发现的具体过程：
服务提供者启动，向注册中心注册自己提供的服务
消费者启动，向注册中心订阅自己需要的服务
注册中心返回服务提供者的列表给消费者
消费者从服务提供者列表中，按照软负载均衡算法，选择一台发起请求
服务监控
集群容错
负载均衡
- Random Loadbalance
- RoundRobin
- LeastActive
- ConsistentHash
dubbo服务治理优势
- 注册中心只负责注册查找，不负责请求转发，压力小
- 注册中心宕机影响消费者，消费者本地缓存服务地址列表
- 注册中心对等集群，宕掉一台自动切换到另外 一台
- 服务提供者无状态，可动态部署，注册中心负责推送
- 统计无压力，本地内存中累计次数，每分钟发送注册中心
- 消费者调用服务者，自动软负载均衡
- 通过服务中心可追踪依赖关系
- 监控中心为扩容和降级提供依据
- 可启用acl机制进行鉴权
- 与Spring整合，接入简单松耦合
- 多种序列化协议支持
dubbo的不足
- 消费者仍需要依赖配置中心
- 消费者仍需要依赖jar包配置provider
- 提供者文档管理功能缺失
- 无统一入口
- 不支持OAuth2.0
- 内部鉴权不方便管理
- 无外部应用鉴权
- 接口基本裸奔，无法直接对外暴露服务
- IT治理不方便
微服务
现在很多人都在谈微服务，那么到底什么是微服务呢？这里谈谈我对微服务的理解。
微服务有两个核心：
- 微：服务的粒度要细，即服务要细化到API
- 服务：提供好服务，要让用户感到好用(要做到这一点很不容易)
微服务（Microservices）是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
微服务架构 ≈ 模块化开发 + 分布式计算
从上面这幅图看出，微服务特别简单（好的架构就应该简单），我们把服务再拆分成一个个API，API是一个完整的功能。然后我们把API扔到一个“云上”，然后用户就可以到“云上”获取所有API的服务，这个“云”保证能提供好的服务。
我们可以看到，有了微服务之后，服务对用户来说变得特别简单，而且上面dubbo的不足之处在微服务这里都解决了。使用者不再需要依赖任何jar包，不再需要去注册中心查找服务，不再去做鉴权处理，不用担心服务挂掉，不用担心不会使用服务，所有的问题这个“云”都解决了。这也是微服务的核心之一，提供好服务。
说到这里，大家就应该大体知道该怎么做微服务了，图中的“云”是关键。下面我们就慢慢拨开这朵云。
微服务的实现
微服务的关键是服务网关，所以，上面提到的“云”就是服务网关。要做微服务，我们先定义一下微服务需要具备的特点。
常见的微服务组件及概念：
- 服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
- 服务发现：服务调用方从服务注册中心找到自己需要调用的服务的地址。
- 负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。
- 服务网关：服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。
- 配置中心：将本地化的配置信息（properties, xml, yaml 等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。
- API 管理：以方便的形式编写及更新 API 文档，并以方便的形式供调用者查看和测试。
- 集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
- 分布式事务：对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。
- 调用链：记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。
- 支撑平台：系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。现在，可以通过 Docker 等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。严重点，以我们两年的实践经验，可以这么说，如果没有合适的支撑平台或工具，就不要使用微服务架构。
微服务架构的优点：
- 降低系统复杂度：每个服务都比较简单，只关注于一个业务功能。
- 松耦合：微服务架构方式是松耦合的，每个微服务可由不同团队独立开发，互不影响。
- 跨语言：只要符合服务 API 契约，开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响。
- 独立部署：微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得 CI／CD 成为可能。
- Docker 容器：和 Docker 容器结合的更好。
- DDD 领域驱动设计：和 DDD 的概念契合，结合开发会更好。
微服务架构的缺点：
- 微服务强调了服务大小，但实际上这并没有一个统一的标准：业务逻辑应该按照什么规则划分为微服务，这本身就是一个经验工程。有些开发者主张 10-100 行代码就应该建立一个微服务。虽然建立小型服务是微服务架构崇尚的，但要记住，微服务是达到目的的手段，而不是目标。微服务的目标是充分分解应用程序，以促进敏捷开发和持续集成部署。
- 微服务的分布式特点带来的复杂性：开发人员需要基于 RPC 或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。
- 分区的数据库体系和分布式事务：更新多个业务实体的业务交易相当普遍，不同服务可能拥有不同的数据库。CAP 原理的约束，使得我们不得不放弃传统的强一致性，而转而追求最终一致性，这个对开发人员来说是一个挑战。
- 测试挑战：传统的单体WEB应用只需测试单一的 REST API 即可，而对微服务进行测试，需要启动它依赖的所有其他服务。这种复杂性不可低估。
- 跨多个服务的更改：比如在传统单体应用中，若有 A、B、C 三个服务需要更改，A 依赖 B，B 依赖 C。我们只需更改相应的模块，然后一次性部署即可。但是在微服务架构中，我们需要仔细规划和协调每个服务的变更部署。我们需要先更新 C，然后更新 B，最后更新 A。
- 部署复杂：微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。此外，我们还需要服务发现机制，以便服务可以发现与其通信的其他服务的地址。因此，成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。
- 总的来说（问题和挑战）：API Gateway、服务间调用、服务发现、服务容错、服务部署、数据调用。
微服务要解决的问题
上面提到了，dubbo还存在一些问题 ，其实dubbo存在的问题 就是 微服务要解决的问题，这里 再总结一下。当然，dubbo和微服务的侧重点不一样，dubbo侧重于内部接口之间的RPC，而微服务则侧重于对外提供服务。
- 统一入口
- 安全控制：防刷限流
- 统一鉴权：应用鉴权、用户鉴权、OAuth鉴权、ACL
- 协议转换：http、dubbo、Protobuf
- API配置管理
- API上线、下线
- API与服务接口映射
- 监控与报警
- 整体架构的可拓展、高并发、分布式
- 服务容器自动收缩、扩容
实现方案
- 负载均衡层：nginx/lvs/F5
- 微服务层
高性能服务网关;
统一入口、API配置管理、分流鉴权、服务监控、协议转换;
API映射、OAuth2.0、API文档管理;
分布式、可拓展;
- 服务治理层
成熟的服务治理框架dubbo;
MQ服务之间解耦;
- 弹性云
服务docker化;
基于访问压力的实时集群调度与管理;
弹性云
这里简单介绍一下弹性云的概念，微服务要想提供好服务，保证API不能挂掉并且有好的性能，需要很高的运维要求。这里的弹性云便是自动化运维解决方案，对访问压力进行监控，根据监控解决调度应用的发布和回收。
服务网格（Service Mesh）
2017 年底，非侵入式的 Service Mesh 技术从萌芽到走向了成熟。
Service Mesh 又译作“服务网格”，作为服务间通信的基础设施层。
如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。
Service Mesh 的来龙去脉：
- 从最原始的主机之间直接使用网线相连
- 网络层的出现
- 集成到应用程序内部的控制流
- 分解到应用程序外部的控制流
- 应用程序的中集成服务发现和断路器
- 出现了专门用于服务发现和断路器的软件包/库，如 Twitter 的 Finagle 和 Facebook 的 Proxygen，这时候还是集成在应用程序内部
- 出现了专门用于服务发现和断路器的开源软件，如 Netflix OSS、Airbnb 的 synapse 和 nerve
- 最后作为微服务的中间层 Service Mesh 出现
Service Mesh 有如下几个特点：
- 应用程序间通讯的中间层
- 轻量级网络代理
- 应用程序无感知
- 解耦应用程序的重试/超时、监控、追踪和服务发现
Service Mesh 架构图：
关于微服务和服务网格的区别，我的一些理解：微服务更像是一个服务之间的生态，专注于服务治理等方面，而服务网格更专注于服务之间的通信，以及和 DevOps 更好的结合。
---------------------
Reference:
1，微服务架构初探