DevilKing's blog

原文链接

Apache Pinot – a distributed, OnLine Analytical Processing (OLAP) system designed for performing low latency analytical queries on terabytes-scale data

Having a real-time dashboard of different events such as consumer demand, driver availability, or trips happening in a city is crucial for day-to-day operation, incident triaging, and financial intelligence.

The different components of this architecture can be categorized into 3 phases:

• Ingestion
• Storage
• Query

关于types部分的定义，

通过同presto的结合来加速查询部分的满足

原文链接

Our goal with DOMA is to provide a way forward for organizations that want to reduce overall system complexity while maintaining the flexibility associated with microservice architectures.

The key characteristic of microservice architecture is the way in which code is hosted, called, and deployed.

The core principles and terminology associated with DOMA are as follows:

1. Instead of orienting around single microservices, we oriented around collections of related microservices. We call these domains.
2. We further create collections of domains which we call layers. The layer that the domain belongs to establishes what dependencies the microservices within that domain are allowed to take on. We call this layer design.
3. We provide clean interfaces for domains that we treat as a single point of entry into the collection. We call these gateways.
4. Finally, we establish that each domain should be agnostic to other domains, which is to say, a domain shouldn’t have logic related to another domain hard coded inside of its code base or data models. Since frequently teams do need to include logic in another team’s domain (for example, custom validation logic or some meta context on a data model), we provide an extension architecture to support well defined extension points within the domain.

we established the following five layers.

1. Infrastructure layer. Provides functionality that any engineering organization could use. It’s Uber’s answer to the big engineering questions, such as storage or networking.
2. Business layer. Provides functionality that Uber as an organization could use, but that is not specific to a particular product category or line of business (LOB) such as Rides, Eats, or Freight.
3. Product layer. Provides functionality that relates to a particular product category or LOB, but is agnostic to the mobile application, such as the “request a ride” logic which is leveraged by multiple Rides facing applications (Rider, Rider “Lite”, m.uber.com, etc).
4. Presentation. Provide functionality that directly relates to features that exist within a consumer-facing application (mobile/web).
5. Edge Layer. Safely exposes Uber services to the outside world. This layer is also mobile application aware.

At Uber, we calculated that the half-life of a microservice was 1.5 years, which means that every 1.5 years 50% of our microservices churn. Without gateways it’s easy for a microservice architecture to fall into a “migration hell” as a result of this churn. Ever changing microservices constantly require upstream migrations. Gateways enable teams to avoid dependencies on the underlying domain services, which means those services can change without forcing an upstream migration.

周期时间

人生就是一段段的陪伴，有长的陪伴，也有短的陪伴。。

尽量在每一段陪伴上，带来欢乐，带来美好，就可以了。。。

原文链接

微服务框架大体可以分为以下四个种类。

第一类是无服务治理的，这一类基本可以看做是一个RPC框架。RPC发展到现在已经有几十年的时间了，主要代表为gRPC、BRPC、Thrift，它们也都有对外开源的代码。

第二类是带治理功能，但是语言比较单一，主要的代表是以Java为主的Spring Cloud、dubbo等。

第三类就是Service Mesh，主要代表产品是Linkerd和ISTIO，这是未来的发展方向。

最后就是TARS，不仅支持多语言，还附带一些服务治理相关的功能产品。

服务配置管理，分为应用配置，SET配置，服务配置，和节点配置

GRPC

服务的实现主要依赖于gRPC拦截器的实现，通过拦截器可以实现远程日志、监控上报、链路追踪等服务。gRPC可以在RPC调用前触发注册的拦截器，在调用前可以执行远程日志上报等等功能，通过多种拦截器串行，实现一个拦截器链路，最终实现各种插件。

service mesh部分:

每个服务下面都有一个Proxy，Proxy就是Sidecar，用于处理服务网格中所有服务的所有入站和出站流量。Proxy把所有的头转给Mixer，Mixer是负责提供策略控制和遥测收集的组件服务，这一块是做数据平面的一些操作。接着是Adapter，为Mixer提供扩展服务的独立服务，比如做一些远程负载均衡的流量控制。以这一套架构作为分布式体系的一部分，能大幅度降低许多单体应用的开发成本。

Pilot主要职责是向 Sidecar 发现服务、信息和各种流量管理和路由规则，Galley服务提供配置的校验、各种配置之间统筹，为 Istio 提供配置管理服务，Citadel用于密钥管理和证书管理，下发到Sidecar等负责通讯转发的组件。

原文链接

we needed to handle over 25,000 inferences per second (and over 1 billion inferences per day), at a latency of under 20ms

benchmark的重要性