以一个架构师的视角，来看最近的.NET Core 2和C#
最近，由于客户等方面的咨询增加，我决定为了自己整理一下在语言和框架选择、在微服务中的应用、在容器（如Docker）中的应用以及大量的REST API访问等方面的问题。
OSS (开放源码软件)
虽然尚有人认为它仍是专有软件，但.NET Core实际上是开源软件，使用了MIT和Apache许可证，并且不仅有微软公司参与开发，还有Redhat和JetBrains等公司也参与贡献。
如果有任何不满意的地方，可以进行修正，并且可以贡献自己的力量。
请提供下列内容的中文本地化版本，只需要一个选项：
https://github.com/dotnet/core/blob/master/roadmap.md
用语言
一旦团队成员掌握了语言后，会考虑在未来的项目退出或职业转换后是否能够继续应用该语言等各种因素。
从维护开发后的软件资产的角度来看，标准化机构如ECMA International和国际标准化组织(ISO)也是重要的因素。
虽然存在一些细微的差异，如服务器端、Unity、Unreal、使用Xamarin的移动应用、适用于Windows的桌面应用程序(UWP)、控制台应用程序等，但因为它们都是基于C#语言开发的，所以可以在各种场景中使用。
进行开发
舒适的开发环境对于提高开发者的生产力是必不可少的，而且创建开发环境需要遵循很多繁琐的规则。有些人可能认为只能在Windows上进行开发，但实际上只需要一个SDK，就可以在Mac或Linux上进行开发。
请点击以下链接，以获取有关Microsoft .NET Core的更多信息：https://www.microsoft.com/net/core#windowscmd
根据个人喜好，可以使用重型强大的类似于Visual Studio的IDE，也可以选择轻量级的类似于VS Code的IDE，还可以使用JetBrains的工具，也可以选择Emacs或Vi等。还有Visual Studio for Mac也是一种选择。根据个人喜好，可以使用喜欢的编辑器。
应用程序可移植性，跨平台
即使你写了一个通用程序，如果要为每个平台都重新编写，那将变得非常麻烦。实现跨平台是非常重要的，只需编译程序，然后生成相应的可执行文件即可。
$ dotnet publish -c Release -r win10-x64
$ dotnet publish -c Release -r linux-x64
$ dotnet publish -c Release -r osx-x64
$ dotnet publish -c Release -r linux-arm
只需要一种选项：接下来，只需将为每个平台生成的文件夹复制并赋予执行权限，然后运行即可。为了实现持续集成（CI）/持续交付（CD）/持续监控（CM）等流程，需要准备测试环境等内容，但交付会更加轻松。
集装箱
最近越来越常听到积极利用和使用容器的话题，当然了，部署到容器中也变得很轻松。
只需准备以下类似的Docker文件：
FROM microsoft/dotnet:2.0-sdk AS build-env
WORKDIR /app
# copy csproj and restore as distinct layers
COPY *.csproj ./
RUN dotnet restore
# copy everything else and build
COPY . ./
RUN dotnet publish -c Release -o out
# build runtime image
FROM microsoft/dotnet:2.0-runtime
WORKDIR /app
COPY --from=build-env /app/out ./
ENTRYPOINT ["dotnet", "dotnetapp.dll"]
只需要创造一个形象就可以了。
$ docker build -t dotnetapp-prod .
$ docker run --rm dotnetapp-prod
Hello .NET Core from Docker
网络服务器
ASP.NETは、かつて重いと言われ続けていましたが、その原因はフロントエンドのウェブサーバであるIISがモジュラー型であり、完全な機能を持つWebサーバだったためでもあります。
現在は、Node.jsや他の軽量TCPサーバライブラリ（libuvやRIOなど）を使用した、非同期IO実装のWebサーバであるKestrelが利用可能です。
Kestrel在高速的同时，没有像高功能的Web服务器那样的架构，当然可以直接运行作为面向微服务的REST API，也可以作为Nginx的后端运行，当然也可以在IIS上运行。
以下有使用TechEmpower测试的IIS/NodeJS/Scala/Netty等进行比较基准的源代码。
由于环境和实现的不同，吞吐量当然会有所变化，但它可能会在某种程度上提供一些参考。
虽然这不仅仅是关于RPS的请求处理数量的竞争，但是可以参考到的是，Kestrel似乎在Scala、Netty和NodeJS类似的位置上可以使用。
以下是原文的中文简述：
https://github.com/aspnet/benchmarks
请点击上方链接访问 “aspnet/benchmarks” 的 GitHub 页面。
实验的基准线
这些是用来测量除了HTTP之外技术栈和方法的服务器实验。
这些通常是TCP服务器，而不是实际的HTTP服务器，专门响应带有固定HTTP响应的HTTP请求。
请用中文将以下内容改述，只需提供一种选项 ：
普通文本
TechEmpower测试和普通文本基准测试相似。
它旨在强调服务器和堆栈的HTTP效率。
实现上，可以自由地缓存响应正文并删除/禁用不必要的组件以最大化性能。
使用 HTTP 管线化的纯文本
与上述的纯文本场景类似，但启用了深度为16的HTTP流水线。只包含有流水线改进的堆栈/服务器。
Scalaperfsvr1,514,94232 threads, 1024 connectionsThe actual TechEmpower Scala plaintext appCPU is 100%, 70% in user modeNettyperfsvr2,808,51532 threads, 256 connectionsThe actual TechEmpower Netty appCPU is 100%
总结
以前与C＃语言相比，在考虑到其应用范围时，最近我开始觉得并不那么糟糕了。
虽然它成为OSS还有不到几年的时间，但我感觉它已经进入了充分的实用领域。
